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.