Another related question: Is there any production software system so inefficient that it would run faster if implemented in machine language on the AGC
I ran Node with --print-opt-code and had Opus look at Turbofan's output. It was able to add comments to the JIT'ed code and give suggestions on how to improve the JavaScript for better optimization.
I've implemented Atari 2600 library support for both LLVM-MOS and CC65, but there are too many compromises to make it suitable for writing a game.
The lack of RAM is a major factor; stack usage must be kept to a minimum and you can forget any kind of heap. RAM can be extended with a special mapper, but due to the lack of a R/W pin on the cartridge, reads and writes use different address ranges, and C does not handle this without a hacky macro solution.
Not to mention the timing constraints with 2600 display kernels and page-crossing limitations, bank switching, inefficient pointer chasing, etc. etc. My intuition is you'd need a SMT solver to write a language that compiles for this system without needing inline assembly.
I've worked on and off on my own personal system which leaves the filesystem stuff to filesystems, and focuses on verifying backups/mirrors and recursing into archive formats. Also interested in warning of near-obsolete formats, like my collection of RealAudio files that are hard to decode these days.
In some early computers, the bootstrap was actually a matrix of diodes where you'd remove a diode to get a one and leave it in for a zero. I had a bunch of these boards sometime in the mid 1970's and found you could program a fully populated board with a 9V battery - basically connect it across a diode in a bit position where you wanted a '1', there would be a small but pretty flash from inside the glass case as a zero turned into a one.
When things like the 74S188 were available, we had so much fun squeezing bootstrap code for PDP11's into 2 of them; 32 words by 16 bits was more than enough (later I got code that would boot five different devices into 256 words).
I used FreeBSD as my daily desktop for a while in the 2000s. IIRC, the package manager had to compile each package from source, but that wasn't a huge deal. Things just worked in a non-overly-clever fashion.
I use "aider --commit" sometimes when I can't think of a comment. I often have to edit it because it's too general or it overstates the impact (e.g. "improved the foo", are you sure you improved the foo?) but that's not limited to local models. I like gemma3:12b or qwen2.5-coder:14b, not much luck with reasoning models.
Even easier is the 1-bit DPCM codec used on the NES. Go up or down one step each sample depending on the next bit. You can't get a square wave out of it, only a triangle, but it has a nostalgic quality.
The NES DPCM runs at up to 33kHz, so it actually has double the bitrate of the 2-bit 8kHz encoding used in the article. If you run it at 16kHz to match the bitrate, it will sound much worse.
