Counterpoint: I picked it up in high school and I was Not That Bright(tm).
Certainly, some complex instruction-set extensions or sprawling SIMD mnemonics are more challenging that what I was reading in the 90s, but the boogie-man status of assembly is greatly overstated.
The final thesis, that we can-and-should let LLMs micro-optimize assembly into non-statically-verifiable gibberish to save an instruction stacks misunderstandings on top of misunderstandings. Just vapid gold-rush cheer-leading from Wired.
I picked it at the age of 11 years old or thereabouts.
Somehow it got fantasized as being hard.
I would go a step further, eventually we might be able to compile directly from high level prompts into Assembly instead of the high level languages like everyone is doing now.
It is the new coming of CASE tools, just needs to mature a bit more, lets see how far this AI cycle goes.
Re your counterpoint, learning to write small extremely toy programs in assembly isn’t hard. But using it to write bug-free programs with non-trivial functionality is much more difficult.
Generally, people aren't writing programs with non-trivial functionality in assembly; they're writing very small, hyper optimized functions that get called by some higher level language.
Exactly ^^^ I taught myself assembly on my Commodore 64. However, I only used it for certain tasks that were suboptimal with Commodore's BASIC and 64K of RAM.
Yeah it's all shit and giggles until you need to allocate memory and handle it. Or when you need to use vector instructions or some CPU-specific stuff. Then you start understanding why people call it nightmarish
Programming in assembly isn't hard, it's just incredibly tedious. Doing manual linearization of an expression DAG, or manual register allocation, or manual control-flow layout very rarely adds any extra value compared to what the compiler will do for you.
As for the idea that AI can optimize code better if we give it assembly code, that's called a peephole superoptimizer, and we've known about it for quite some time ([1], which cites the first relevant paper as being from 1987). It's not new, and it's actually been used to improve the peepholes of compilers for quite same time now. The main limiting factor is probably in our ability to prove correctness of the code generated by search algorithms.
The klever idea of using llms instead of superoptimisers is to drop the correctness requirement. You get some shorter code that does a different thing, maybe it'll still do something you like.
I have been playing with the idea of an LLM native programming language focusing on token efficiency, comprehension, and attention. It is interesting to see what the various large models come up with. A common theme actually reminds me quite of bit of assembly. The verb prefixing, limited statements per line, small concept surface area all appeared in multiple conversations across several larger models. The big difference being assembly lacks semantic meaning leaving some benefit on the table. I still cannot believe what some did with the tech, RCT is such a retro favorite.
I enjoyed assembly programming in uni but haven’t done much since. This take to rewrite everything in it tends to pop up every now and then, and I think the last line sums pretty well why it never actually happens:
“It was probably just his imagination, but the display had been a little laggy, he thought. He’d redo the code if he could, he said. But alas, Sawyer and the machine did not speak the same assembly language.”
I firmly believe that all programmers, even you, should be forced to program a microcontroller in assembly at least once.
IMO the utter lack of awareness that our abstractions represent a physical machine with real hardware that operates in finite time is why software today is so bad. Our languages are so far removed from the hardware that the CPU and its finite resources simply don't exist for most programmers. Many of the rising generation of engineers have no clue how a CPU works, what a register is, or what the cost of reading and writing to RAM is.
Assembly is not so difficult as to be unapproachable for beginners. Remember, back in the day we all started in assembly and produced a generation of absolutely brilliant engineers and scientists. We all had to understand the physicality of the real machine and we had to make the best we could with very constrained resources.
I'm not a great programmer and don't code full time, but I've done a bit of that 8bit assembler and enjoyed the relatively finite single-focused determinism of it, but I don't know if it has improved my current coding at all.
I suspect doing some Linux systems coding in C might have a bigger effect on connecting the dots between the layers for me.
I'm so tired of this bullshit mystique around assembly: "you saw craftsmanship so obsessive that it bordered on insane. Chris Sawyer, the game’s sole developer, wrote the whole thing in assembly."
There's nothing insane about writing games or other programs in assembly language. It takes longer than writing them in C or JS, sure. Debugging them becomes more difficult. Sometimes you can achieve results that way you can't achieve in higher-level languages. But it's not some kind of superhuman wizardry. Assembly language is actually simpler than the higher-level languages. Virtually all videogames for the Nintendo were written in assembly. People have written entire operating systems in assembly.
It's not "brutal". It just takes longer, that's all. People like to set up hierarchies of languages based on what's more difficult, but I think that's kind of juvenile: teenage boy one-upmanship. Solving puzzles is fun, but anybody can learn to solve them.
Assembly-language programs can be beautiful. So can programs in any language. Usually they aren't.
I am coding my own wayland compositor, in rv64 assembly... running on x86_64 with a small interpreter.
I am currently only using the core ISA (no compressed instructions, not even the pseudo instructions), and I use a C preprocessor to avoid to get my code locked on the preprocessor of one assembler.
I started to code assembly when I was a teenager as it is not hard: only uncomfortable. Nowdays, with what seems a real global, no IP locks, ISA, RISC-V, it is very reasonable to write directly assembly, as (real and sane) standard assembly is extremely efficient at fighting planned obsolecence.
Oh ok. I have been trying to write emulator and validating if instruction is correctly implemented in my code has been biggest pain point for me as I have no idea to get reference in something like instruction - opcode - context before execution - context after execution.
Only thing which I have come up with is just step through the instructions on the MCU using compiled output from yarpgen, but problem here is that it wont generate code variable enough to test all the instructions, so there are going to be blind spots like i.e. float divisions, SIMD instructions etc.
"Assembly is Brutal"
Counterpoint: I picked it up in high school and I was Not That Bright(tm).
Certainly, some complex instruction-set extensions or sprawling SIMD mnemonics are more challenging that what I was reading in the 90s, but the boogie-man status of assembly is greatly overstated.
The final thesis, that we can-and-should let LLMs micro-optimize assembly into non-statically-verifiable gibberish to save an instruction stacks misunderstandings on top of misunderstandings. Just vapid gold-rush cheer-leading from Wired.
I picked it at the age of 11 years old or thereabouts.
Somehow it got fantasized as being hard.
I would go a step further, eventually we might be able to compile directly from high level prompts into Assembly instead of the high level languages like everyone is doing now.
It is the new coming of CASE tools, just needs to mature a bit more, lets see how far this AI cycle goes.
Re your counterpoint, learning to write small extremely toy programs in assembly isn’t hard. But using it to write bug-free programs with non-trivial functionality is much more difficult.
Generally, people aren't writing programs with non-trivial functionality in assembly; they're writing very small, hyper optimized functions that get called by some higher level language.
Exactly ^^^ I taught myself assembly on my Commodore 64. However, I only used it for certain tasks that were suboptimal with Commodore's BASIC and 64K of RAM.
Or in my case, 68K assembly for genesis/megadrive homebrew -- mostly to do VDP display interrupt tricks.
Yeah it's all shit and giggles until you need to allocate memory and handle it. Or when you need to use vector instructions or some CPU-specific stuff. Then you start understanding why people call it nightmarish
Programming in assembly isn't hard, it's just incredibly tedious. Doing manual linearization of an expression DAG, or manual register allocation, or manual control-flow layout very rarely adds any extra value compared to what the compiler will do for you.
As for the idea that AI can optimize code better if we give it assembly code, that's called a peephole superoptimizer, and we've known about it for quite some time ([1], which cites the first relevant paper as being from 1987). It's not new, and it's actually been used to improve the peepholes of compilers for quite same time now. The main limiting factor is probably in our ability to prove correctness of the code generated by search algorithms.
[1] https://www.cse.iitm.ac.in/~krishna/courses/2022/odd-cs6013/...
The klever idea of using llms instead of superoptimisers is to drop the correctness requirement. You get some shorter code that does a different thing, maybe it'll still do something you like.
I have been playing with the idea of an LLM native programming language focusing on token efficiency, comprehension, and attention. It is interesting to see what the various large models come up with. A common theme actually reminds me quite of bit of assembly. The verb prefixing, limited statements per line, small concept surface area all appeared in multiple conversations across several larger models. The big difference being assembly lacks semantic meaning leaving some benefit on the table. I still cannot believe what some did with the tech, RCT is such a retro favorite.
I enjoyed assembly programming in uni but haven’t done much since. This take to rewrite everything in it tends to pop up every now and then, and I think the last line sums pretty well why it never actually happens:
“It was probably just his imagination, but the display had been a little laggy, he thought. He’d redo the code if he could, he said. But alas, Sawyer and the machine did not speak the same assembly language.”
https://archive.ph/jV1CI
I firmly believe that all programmers, even you, should be forced to program a microcontroller in assembly at least once.
IMO the utter lack of awareness that our abstractions represent a physical machine with real hardware that operates in finite time is why software today is so bad. Our languages are so far removed from the hardware that the CPU and its finite resources simply don't exist for most programmers. Many of the rising generation of engineers have no clue how a CPU works, what a register is, or what the cost of reading and writing to RAM is.
Assembly is not so difficult as to be unapproachable for beginners. Remember, back in the day we all started in assembly and produced a generation of absolutely brilliant engineers and scientists. We all had to understand the physicality of the real machine and we had to make the best we could with very constrained resources.
Does Z80 or 6502 on 8bit computers count?
I'm not a great programmer and don't code full time, but I've done a bit of that 8bit assembler and enjoyed the relatively finite single-focused determinism of it, but I don't know if it has improved my current coding at all.
I suspect doing some Linux systems coding in C might have a bigger effect on connecting the dots between the layers for me.
I'm so tired of this bullshit mystique around assembly: "you saw craftsmanship so obsessive that it bordered on insane. Chris Sawyer, the game’s sole developer, wrote the whole thing in assembly."
There's nothing insane about writing games or other programs in assembly language. It takes longer than writing them in C or JS, sure. Debugging them becomes more difficult. Sometimes you can achieve results that way you can't achieve in higher-level languages. But it's not some kind of superhuman wizardry. Assembly language is actually simpler than the higher-level languages. Virtually all videogames for the Nintendo were written in assembly. People have written entire operating systems in assembly.
It's not "brutal". It just takes longer, that's all. People like to set up hierarchies of languages based on what's more difficult, but I think that's kind of juvenile: teenage boy one-upmanship. Solving puzzles is fun, but anybody can learn to solve them.
Assembly-language programs can be beautiful. So can programs in any language. Usually they aren't.
Assembly is not that hard. I taught myself to program Z80 assembly on the ZX Spectrum when I was 11 and wrote a small platform game with it.
I am coding my own wayland compositor, in rv64 assembly... running on x86_64 with a small interpreter.
I am currently only using the core ISA (no compressed instructions, not even the pseudo instructions), and I use a C preprocessor to avoid to get my code locked on the preprocessor of one assembler.
I started to code assembly when I was a teenager as it is not hard: only uncomfortable. Nowdays, with what seems a real global, no IP locks, ISA, RISC-V, it is very reasonable to write directly assembly, as (real and sane) standard assembly is extremely efficient at fighting planned obsolecence.
How did you validate correctness of your interpreter?
I have been using only basic RISC-V core machine instructions: the interpreter is beyond stupid, I did write it directly in x86_64 assembly.
Oh ok. I have been trying to write emulator and validating if instruction is correctly implemented in my code has been biggest pain point for me as I have no idea to get reference in something like instruction - opcode - context before execution - context after execution.
Only thing which I have come up with is just step through the instructions on the MCU using compiled output from yarpgen, but problem here is that it wont generate code variable enough to test all the instructions, so there are going to be blind spots like i.e. float divisions, SIMD instructions etc.
https://github.com/intel/yarpgen
I'm surprised everyone is just buying into this premise and not acknowledging what nonsense this title is.