RE: https://lingo.lol/@thedansimonson/116156498254821672
this is also why LLMs are not "another layer of abstraction". do you need to read the asm output of your compiler every time it runs? no, and having to do so would substantially reduce the value of said compiler
@jcoglan I've written a short post about a related topic: LLMs are the opposite of DRY: https://cs.wellesley.edu/~pmwh/advice/aiDRY.html
I just read a security post that talked about an AI code review process successfully rejecting poisoned instructions that attempted to manipulate it into using it's permissions to let a bad actor in. The post made it seem like this was good "defense in depth" but to anyone thinking about it for a minute, you can see that this isn't reliable. There's no explanation to be had for why the bot recognized that the instructions were manipulative and didn't follow them, and thus no guarantee that it would have the same reaction again, even given the exact same input! In fact, it's highly likely that a bit better prompt engineering would indeed make the system into a liability, rather than an asset.
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.
@pmorinerie @nicuveo @jcoglan Many subtle points can make compilers non-deterministic in practice. Randomness is a red herring, the real advantage of compilers is the guarantees about run time semantics.
I see many mocking llm as stochastic parrots, but you know what else is non-deterministic? Humans :)
jcoglan
Tiota Sram
Jim Rea
pmorinerie
Antoine Leblanc 
Phairupegiont
Nicolás Alvarez