Posted by 0x54MUR41 7 hours ago
On the other hand, if you write your own non optimizing compiler, you can avoid a lot of these problems by, for example, tracking what registers a function writes and ensuring they are saved before a call and restored after. Then you can actually get the raw performance of handwritten asm without the pitfalls (the resulting code would still he harder to read and maintain than equivalent high level code, but at least it would be tractable). Even better, you can write your own high level assembler that is actually portable to other architectures. For example, instead of directly modeling x86_64, your compiler can model a cpu with 16 general purpose registers and a set of instructions that map to x86_64 instructions. An arm port would be straightforward since arm also has 16 general purpose registers and you can model x86_64 instructions as one or more arm instructions (and you have extra registers for x86_64 instructions that must be modeled as multiple arm instructions). Or you could do the reverse and model 32 general purpose registers using arm instructions and use predefined memory slots as virtual registers on x86_64.
Sure, they might make all sorts of dumb hypotheses at first, but as long as the results of those stay in their context, they do seem to eventually “run out of ways to be stupid.” (Which is to say, LLMs seem to experience in-context learning even via self-directed trial-and-error, if given a sufficiently-large number of iterations and no way to cheat.)
It also is an excellent radare2/rizin/ghidra driver as well. Maybe it's because its ~cyber~ capabilities (pretty much linked with assembly-level knowledge) aren't guardrailed off?
My output is linux/amd64 assembly language which is compiled by nasm. I don't link to glibc, so I had to implement my "print int", "print string", and similar primitives in raw assembly.
I successfully implemented a stop© garbage collector, and other interfaces to the OS such as reading command-line arguments, environmental variables, and so on. All in assembly. Though my compiler is written in golang the runtime, and all supporting functions have to be in assembly to make sure that the binaries it produced are static.
(I wrote a lisp interpreter which can be compiled, and which can be used to run itself, so I got an indirect REPL.)
But assembly? I'm not sure, honestly. Architectures change, and you can easily converge to good code by talking to an LLM.
May I ask why you didn't use LLVM as a target?
IME while LLMs may help delivery utility in a finished work, humans often value the absorption, mastery, style, or constraint of performing a mundane activity hands-on and brains-on.
Yes. Its "simplicity" is exactly why we pick and assemble piece by hand - we imagine the leanest way.
LLMs are (not just in Assembly, but especially) very precious as a natural language manual.
> an LLM can easily code it without errors
One day it will probably also be able to have sex, and yet we think we will not pass on the experience - unless, like some kind of coding, it will be a "strictly professional only for money" operation (like in Monty Python's Argument sketch).
Edit: as esteemed emptybits wrote above, rephrasing: it's /the Art of/ Assembly.
Professionally, assembly is the last thing I would let an LLM generate for me. That's because if you need to write something in assembly, it's because it's critical: operating system context switch, interrupt handler, that kind of thing. You don't want to be 99% correct, you need that code to be 100% good.
I can imagine some other professional scenarios that I'm less familiar with, where you want to write a tight numeric loop of NEON64 assembly and let the LLM do it, because it's frankly a pain to do by hand, and you can test it to some degree of confidence.
It’s a hobby.
However, I want to point out the obvious fact that people are still playing the piano in the age of the self-playing piano. Humans are experiential creatures, and we enjoy a wide range of activities for their own sake that may have nothing to do with efficiency of output.
An LLM knowns nothing of the taste of ginger.
can't tell if sarcasm or not. Just in case it's not.. in that case why don't we all vibe everything in assembly? No need for abstractions anymore since that's a human concept. LLM can do it without errors, as you say, and we'll reap the benefits of speed!
I really loved this retort, but we have to reply: from that cone of perspective, it would be probably better to "vibecode" in C and not hope that the LLM does a better job than the compiler (for efficiency, not for absence of bugs as per the original). (Edit: for clarity: some compilers of low level languages are specialized in ASM optimization - the LLM will hardly beat them.)
I keep hearing this for the last 20 odd years, yet I see evidence to the contrary each and every day. It is hard and honest work though.
The original SSE (SIMD) extensions were actually written with this use case in mind. When they first came out, the compilers were awful. They've since caught up.