I don't think it's surprising AI writes faster code in ASM. Too many think ASM is difficult and they can never beat the compiler, but the control it gives makes it easy if you know what you're doing.
This doesn't even account for the bloat from stack canaries/etc that compilers like GCC add, which I'm willing to bet aren't present in his new build.
I ported the Omarchy screensaver engine (ttfx) from Rust to x86-64 assembler, and it's up to 17x faster!! One-shot translation by Opus 5.5. We keep drilling until the agentic drill bit hits bedrock! github.com/omacom/ttfx/pull/…
Finished this book, and it's definitely the best book there is for making the front end of a fully compliant ANSI C'89 compiler.
It doesn't replace the K&R book, but that book leaves a lot out that's important to know for compiler makers.
Granted, the best part of this book is simply the standard, so you don't actually need it, and his annotations could have explained further in many places, but what's there is still very helpful.
And yes, I have 3 copies because they were about $4 each after all said and done, including shipping.
I love seeing companies succeed after taking risks for the people. GG @ketchupent
You asked for it, we delivered, and you showed up! 💥Thank you to the fans for making this a massive hit! Don't miss out on the biggest surprise hit of the year. Go see Coyote vs. Acme in theaters now! 🧨#CoyoteVsAcme
Not to dunk on this person, but I think this painfully illustrates how modern audiences don't even think to read the instructions anymore.
That said, I'll definitely be ignoring modern audiences and doing my own thing, e.g. making manuals to go with the physical editions.
Idk if it's just X, or a generation thing, but the amount of larpers trying to be the arbiters of truth is crazy.
Now they're saying the OG Metroid was never loved...?
I feel dumb for even engaging with such nonsense, as anyone who remembers that era, knows how big it was.
(Photo from EGM's 100 Best Games of All Time issue in 1997.)
(2/2)
Making an ANSI C '89 compliant compiler in 2026 is the most "me" thing I've done in awhile. While all of us C lovers love it for its simplicity, it's surprisingly deep and complex under the hood. Not because of the features, but because how they recursively interact.
It can be genuinely mind-blowing.
While I'm close to being fully operational, chasing the edge cases at the end presents a large unknown as to how long it'll take before it's truly ANSI compliant.
In fact, it would be significantly easier to just write my own language which contains everything most use in C, even if I added additional complexity, like classes, a type checking system, garbage collection, etc.
That said, while the freedom to work independently is the primary reward, the knowledge that can only come from implementing C manually from scratch is valuable beyond measure.
It's why standing before AI and those who can create all I can, faster, I can still smile confidently. Because I am the real deal, and all that I do lives clearly in my brain, and it's just getting better every day.
In summary, to any who may be feeling disheartened seeing what AI is producing, I hope you can see that the pain, suffering, and enduring hardships you continuously endure in trying to do things on your own, is neither meaningless, nor without value. In fact, it is priceless, because it is who you are.
The next steps are:
> Prologues - Basically initializes a function.
> Epilogues - Technically the JR instruction is an epilogue, but real epiloques restore things to the previous state before the function.
> Call Sequence - This is basically the reverse of the epilogue, storing the state before jumping to the function.
> Putting these together.
>> Control Flow (i.e. if/else, switch, while, etc.)
MAIN: label for the main function (obviously).
ORI: Easier for most to think of this as "LI" (Load Immediate), but that instruction is only a pseudo instruction in MIPS I, and considering I'm outputting binary at the same time, I prefer to be more direct. ORI stands for "bitwise or immediate".
$2: This is the MIPS code for the designated function return value register.
$0: This is the zero register (a register that always contains zero).
Thus the instruction is equal to:
Dest ($2) = Src ($0) | 0
JR: MIPS instruction for jumping to the value in a register (aka Jump Register).
$31: The MIPS I code for the return address register.
NOP: the infamous heart of PS1 programming, which basically does nothing, but it's essential after branches in MIPS I due to registers not being reliably loaded for a single instruction.
All of which combines in C to simply to:
int main(){
return 0;
}
(2/2)
I've decided to go all the way and be fully ANSI C compliant, though for the time being it will be just Freestanding before I shift back focus to the games themselves, considering the Hosted libraries get exhausting re-implementing for these old consoles.
That said, it means NULL and EOF will now be part of their respective libraries, and more notably, asm("instructions") will now be replaced by __asm__("instructions"), as the former would break compliance by reserving a keyword outside the standard, whereas the the standard explicitly allows those preceeded by 2 underscores to be reserved by the compiler.
Additionally, I'll also be adding: __reserve_reg__(reg). This is entirely for the later architectures I have planned, which are CISC based, and lack the reliable call sequence of something like MIPS I.
Lastly, I'll likely be adding in said features next, so I'll be able to start updating my game engine to support the PS1, and immediately testing binaries on the emulator (DuckStation).