@jcoglan @nicuveo yes, but…

A while ago, I investigated using the SDCC compiler to write code for the Game Boy Color.

I usually read and write Game Boy code in assembly (that’s how all the GB games were written back then). So I know how to do basic things, how to write an idiomatic array enumeration, a handful of clever (and not really mandatory) assembly tricks, etc.

That said, how nice would it be to write C – instead of spending hours at "how to multiply those numbers"?

Well: it is awful.

@jcoglan @nicuveo for a start, the very-close-to-the-metal constructs don’t map really well to the C language. The C SDK is full of "Use this macro to do magic side effects", some areas of memory become locked or unlocked at specific points…

But the main thing is that the generated code is awfully bloated. Easily 10x the assembly version.

@jcoglan @nicuveo All arguments are passed on the stack. No registers are ever used to pass arguments. The stack routines take dozens of instruction before calling a function, and dozens again in the function epilogue. A trivial function becomes a pile of mess.

Plus, simply doing "complex" maths (e.g "x = 64 / 10") will generate a ton of instructions to divide by a non-power-of-two value. When writing assembly code, this is visible, and worked around. Not in C.

@jcoglan @nicuveo and all of this bloat matters!

This isn’t even about hot loops; more about general bloat. The Game Boy has a very limited number of cycles available each frame – around 10 000 instructions. That’s it. So bloating the code by a factor 10 for no reasons will make you hit the frame budget _very_ quickly.

@jcoglan @nicuveo So, from the point of view of an experienced assembly developer on the Game Boy, C is an absolute waste. Bloated, slow, with leaky abstractions.

Maybe useful in a handful of cases though – like a one-shot large function, out of any critical path, with a lot of maths. Someone used it to generate a maze. But of course the actual gameplay code is assembly.

@jcoglan @nicuveo but besides that…

The Game Boy C SDK exists. It is actively used. Homebrew games have been written with it.

Heck, even my own first experience with C was writing a Pokemon-themed ROM for the Game Boy, with scrolling and basic physics. I didn't knew what a pointer was, but still managed to produce something.

@jcoglan @nicuveo the point is:

When we’re used to a paradigm, and know it well, we quickly see the limitations of a new way. We know immediately what wouldn’t work, what we would loose, what is slow and bloated.

And sometimes those inefficiencies don’t matter that much.

We can’t (seriously) program the Game Boy in C. But for the next generation of machines, it was the way to go. With the time the generated code is a bit less bloated – but mostly it doesn’t matter: the CPU became fast enough.

@jcoglan @nicuveo Now to be clear: fuck GenAI, and fuck the big corps that digest our own work and resell it to us.

I just feel that the argument of ”AI-generated code is a mess!” may be weak.

Sure it is – but maybe it will get slightly better, and for some use-cases it will matter less, and people will use it in non-critical or prototyping or throw-away cases, and it will have some value.