I still consider the Saab Draken one of the most beautiful aircraft ever designed:

https://en.wikipedia.org/wiki/Saab_35_Draken

Especially the top view:

https://www.flyajetfighter.com/wp-content/uploads/2025/09/Sa...

Agreed!

Though I prefer this picture:

https://en.wikipedia.org/wiki/File:20171007130915!Saab_Drake...

Reminds me of Apogees Raptor and similar fighter plane DOS games.

Yes, that's an even better picture! Austrian air-force version, right?

Yes, in some special livery in the colors of the austrian flag!

You're probably thinking of Ian Piumarta's COLA project (Combined Object Lambda Architecture), which had parts named after cola soft-drinks (Coke was a lisp-like language, Pepsi was a Smalltalk-like language, and Jolt was an early implementation of Coke):

https://www.piumarta.com/software/cola/

I think not, but this was a really interesting thing, I'm so glad you introduced me to it, thank you!

Another interesting lisp-like language by Ian Piumarta is Maru, currently hosted here: https://github.com/attila-lendvai/maru

Congrats to the Squeak 6.1 team! I was an early contributor to Squeak from when Alan Kay's group was at Apple (I see that SameGame, the first game implemented in Morphic is still in the image), and still enjoy following the progress of Squeak and all of its spinoffs.

More stories please! :)

Since your language is very "rust-like", what made you choose Ocaml as the implementation language?

Ocaml was very simple to program in to be honest, and has very minimal rules as well so i can be productive with the development of the language, Rust also used ocaml in it's early versions for bootstrapping

The registers could also be partitioned into fixed sizes and protected, to allow for a banked register file that allowed for amazingly fast context switches in RTOS systems.

Yes, I had an architecture professor that was a fan of it (and so your work, presumably!) It's the only way I'd encountered it, sadly.

That was back around 2000 at Loughborough in the UK.

> Well that was basically an am29000 but with an x86 instruction decoder front end.

The K5 was based upon a 29K-family design, but it was actually an un-released superscalar project code-named "Jaguar", rather than just a 29K with an x86 decoder.

Yep, it wound up as the main CPU in a bunch of laser-printers, as well as Apple's 8*24GC QuickDraw accelerator card for the Macintosh, and as part of the flight-control computer on Boeing 777s, among many other embedded system designs.

Wow, blast from the past! I was on the architecture / micro-architecture team for the 29K and 29050, and your story of writing and debugging the emulator brought up similar memories of working on the performance simulator for these chips.

Very impressive work -- congratulations!

Wow! Thank you! The floating-point implementation in the Am29050 is really great as it ran in parallel with the integer unit. Sorry, I need to ask, maybe you don't remember. What happens if you write into gr2-gr63? Not really needed to know, but I've been curious the last 30 years.

The FPU in the 29050 was based on the Am29325 bit-slice family FPU; an extra write port was added to the register file to allow for asynchronous FPU result writeback, which allowed the parallel operation.

gr2 and gr3 were used in the 29050 for FP condition code registers, but otherwise I'm pretty sure accessing the rest caused a trap.

Amazing! I didn't knew about the gr2 and gr3 register. I just searched for these in the user's manual, very sparse documentation. Thank you!

For the sake of archival/computing history, do you know if a copy of the am29k High-C compiler could turn up on archive.org one day?

Fun fact I learned from a Func Prog podcast: the name Steel Bank is a play on it's origin as Carnegie-Mellon Common Lisp (Carnegie made his fortune in Steel, while Mellon did so with Banks):

https://www.sbcl.org/history.html

There's another wordplay in the name.

Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do

In my first job, grumpy Martin had as one of his many indispensable tasks, to build cmucl. (Itasoftware, one of the main lisp shops of the age)

It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.

The sane bootstrap is not about porting to new architecture, but about building the compiler from source in the first place. CMU CL effectively requires that you use the same version of CMU CL to build it, IIRC, which in practice meant you had to first load the changes into older CMU CL image - overwriting core components, and then use that image to compile new version.

The difference with SBCL is that it can compile so long as you have any CL implementation that handles certain broad, but not complete, subset of ANSI CL.

It does it by being able to compile itself in sort-of sandboxed state hosted within another CL image, and then using that compiler to build itself, without requiring to modify the host compiler like CMU

As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all - it had evaluator option, which was indeed dropped for a long time from SBCL but was recently reintroduced, partially to support efforts such as porting Kandria [1] to Nintendo Switch

[1] https://kandria.com/

> As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all

The byte code compilation option is described in CMUCL documentation, section 5.9 Byte Coded Compilation: https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation....

Ah, with how cmucl was problematic to get running I never delved that deep. It indeed is not present in SBCL.

That said, as mentioned, it gave no real impact on bootstrappability nor portability

That's more of a backronym.

We actually did this in my freshman dorm room, as the paint color almost exactly matched the original Crest "green".