Reading this thread leaves me with the impression that most posters advocating learning assembly language have never had to use it in a production environment. It sucks!
For the overwhelming majority of programmers, assembly offers absolutely no benefit. I learned (MC6809) assembly after learning BASIC. I went on to become an embedded systems programmer in an era where compilers were still pretty expensive, and I worked for a cheapskate. I wrote an untold amount of assembly for various microcontrollers over the first 10 years of my career. I honestly can't say I got any more benefit out of than programming in C; it just made everything take so much longer.
I once, for a side gig, had to write a 16-bit long-division routine on a processor with only one 8-bit accumulator. That was the point at which I declared that I'd never write another assembly program. Luckily, by then gcc supported some smaller processors so I could switch to using Atmel AVR series.
I've written assembly in a production environment. I love it and wish I could do more.
But the context where I'm doing it is very different from the context where you had to write a division routine from scratch! We never use assembly where a higher-level language would be good enough. It's only used for things that can't be written in C at all, either because it needs an instruction that the C compiler won't emit, or it involves some special calling convention that C can't express.
However, I read assembly in production all the time. Literally every day on the job. It's absolutely essential for crashes that won't reproduce locally, issues caused by compiler bugs, or extremely sensitive performance work. Now, lots of programmers very rarely have to deal with those sorts of things, but when it comes up, they'll be asking for help from the ones who know this stuff.
I hardly consider myself an expert ARM ASM programmer (or even an amateur...), but a baseline level of how to read it even if you have to look up a bunch of instructions every time can be super useful for performance work, especially if you have the abstract computer engineering know how to back it up.
For example, it turns out that gcc 7.3 (for arm64) doesn't optimize
foo() ? bar() : baz();
the same as
if (foo()) {
bar();
} else {
baz();
}
!
The former was compiled into a branchless set of instructions, while the latter had a branch!
Just curious, what kind of work do you do? Sounds like SRE in FAANG that deals with production systems. I work as a DE and the lowest level thing I have to read is JVM dump from spark. Man I envy you.
> I once, for a side gig, had to write a 16-bit long-division routine on a processor with only one 8-bit accumulator. That was the point at which I declared that I'd never write another assembly program.
This is exactly the kind of job I'd enjoy! A perfectly doable technical challenge with clear requirements. Some people like solving Sudoku puzzles, I like solving programming puzzles.
I guess I'm just not "the overwhelming majority of programmers".
> doable technical challenge with clear requirements
That's a Project Management issue, not an implementation concern.
In my case, there was no requirement that said "use 16-bit long division." However, we had committed to a particular processor family (MC68HC05), and the calculation precision required 16-bit math. IIRC, there was a compiler available, but it cost more than the rest of the project and the code it produced wouldn't have fit into the variant of the processor that I was using anyway.
The actual requirement would have looked more like "detect a 0.1% decrease in signal that persists for 10 seconds, then do X."
I feel the same way, but I also can't help but imagine the boss jumping up and down and throwing chairs and screaming "how can you not be done yet? You're a programmer and this is a program and it's been three _hours_ already".
I think the majority of programmers would enjoy it, but most would first need to pick an ISA (something older is probably going to be more approachable for beginners), learn enough about it to understand basic arithmetic instructions, learn enough about the dev tools to be able to assemble, link, and execute their code, etc.
For most folks, that's going to be a couple days of prep work before they can get to the fun part of solving the puzzle.
"I guess I'm just not the "overwhelming majority of programmers"."
The "overwhelming" majority of programmers may be underwhelming
Some readers may be unimpressed by programmers who complain about and criticise assembly language, e.g., claiming it offers "no benefit" to others, especially when no one is forcing these programmers to use it
I did a lot of assembler programming before discovering C. I learned C in maybe an hour because of that.
Not knowing assembler means programmers have a bit of a blind spot towards what are expensive things to do in C vs what generates the best code.
For example, debugging a program sometimes requires looking at the generated assembler. Recently I was wondering why my deliberate null pointer dereference wasn't generating an exception. Looking at the assembler, there were no instructions generated for it. It turns out that since a null pointer dereference was undefined behavior, the compiler didn't need to generate any instructions for it.
I build web applications that run on top of databases, web servers and frameworks.
I do need to understand how indexes in db engine work, I need to understand there might be socket exhaustion in the system, I do need to understand how my framework allocates data on heap vs stack.
Having to drop to instructions that is for web servers, db, frameworks developers not for me to do. I do have a clue how low level works but there is no need for me.
That is part where parent poster is correct there are better ways for developers to spend time on - trust your database, web servers and framework and learn how those work in depth you can skip asembler, because all of those will take a lot of time anyway and most likely those are the ones you should/can tweak to fix performance not assembler.
The issue is it's a moving target. What was expensive yesterday could be fast today based on compiler optimizations (and potentially vice versa).
Further, changes in the ISA can open up gains in performance that weren't available in yesteryear. An example of this would be SIMD instruction usage.
It's not a bad idea to know enough assembly language to understand why code is slow. However, the general default should be to avoid writing it. Your time would be better spent getting a newer version of your compiler and potentially enabling things like PGO.
> most posters advocating learning assembly language have never had to use it in a production environment... For the overwhelming majority of programmers, assembly offers absolutely no benefit.
I don't follow. Why should assembly have to be useful or pleasant in a production environment, for learning it to be useful?
I was taught a couple different flavours of assembly in university, and I found it quite useful for appreciating what the machine actually does. Certainly more so than C. Abstractions do ultimately have to be rooted in something.
You and the post you commented on display both a valid point. If we're talking about using assembly as a broad general purpose programming environment that would be a mess (which is precisely why it has no broad adoption). When we talk about assembly as a niché special purpose solution we would come to a different conclusion, coincidentally this is where assembly is still used today: environments where we need highly optimized code.
Your point about education is orthogonal to the point made. I agree with you that learning assembly can be a good way to teach people how computers work on a low level, but that has nothing to do with whether it is useful as a skill to learn.
As someone teaching similar things at the university level to a non-tech audience I have to always carefully wheigh how much "practically useless" lessons a typical art student can stomach. And which kind of lesson will just deter them, potentially forever.
Is it useful to learn bagpipes? I guess learning for its own sake is good, but if you want to join a band, guitar or keyboards are going to be a better bet and learning bagpipes first isn't going to do much for you.
> Reading this thread leaves me with the impression that most posters advocating learning assembly language have never had to use it in a production environment. It sucks!
It absolutely sucks. But it's not scary. In my world (Zephyr RTOS kernel) I routinely see people go through all kinds of contortions to build abstractions around what are actually pretty straightforward hardware interfaces. Like, here's an interrupt controller with four registers. And here's a C API in the HAL with 28 functions and a bunch of function pointer typedefs and handler mechanics you're supposed to use to talk to it. Stuff like that.
It's really common to see giant abstractions built around things that could literally be two-instruction inline assembly blocks. And the reason is that everyone is scared of "__asm__".
This exactly. If you are doing embedded programming, direct register access and manipulation is often a far, far superior option, and you don’t have to be some kind of “assembly sensei” to do it if you just have a very basic idea of how things work. It doesn’t mean you write programs in assembly… it means when you are needing to do something that the hardware is going to do for you anyway, you know how to ask for it directly without having to load a 2Kloc library. This is especially true when using python or JS bytecode on the MCU. Actually, using python with assembly is really the best of both worlds in many cases.
Yeah, but doesn't the Zephyr device tree abstraction actually expect you to do that? I mean, I appreciate the elegance and the desire for portability, but all I could think of as I read those docs was "here's a couple months of work for something that should take ten minutes."
Most of us do not have the chance to use it in production. I think that's where the fancy came from.
We are also getting burned out by the modern Agile web/data/whatever development scene and would like to drill really deep into one specific area without stakeholders breathing down our necks every few hours, which assembly programming conveniently provides.
I also consider the grit (forced or voluntary) to be a bath of fire which significantly improved two important things - the programmer's understanding of the system, and the programmer's capability to run low level code in his brain. Is it suffering? Definitely, but this is a suffering that bring technical prowess.
Most of us do not have the privilege to suffer properly. Do you prefer to suffer from incomplete documentation, very low level code and banging your head on a wall for tough technical problems, or do you prefer to suffer from incomplete documentation, layers and layers of abstraction, stakeholders changing requirements every day and actually know very little about technical stuffs? I think it is an easy choice, at least for me. If there is an assembly language / C job that is willing to take me in, I'll do it in half of the salary I'm earning.
I started my career in assembly and it's reduced over time. Towards the end of the gamedev work I was still reading a lot of assembly but no longer writing it (using intrinsics instead). It was definitely a lot slower to write.
But there are a number of things we did that are not available or difficult in C:
- Guaranteed tail calls
- Returning multiple values without touching memory
- using the stack pointer as a general purpose pointer for writing to memory
- Changing the stack pointer to support co-routimes
- Using our own register / calling convention (e.g. setting aside a register to be available to all routines
- Unpicking the stack to reduce register setup for commonly used routines or fast longjmps
- VM "jump tables" without requiring an indirection to know where to jump to
On 8-bit home computer CPUs like the 6502 or Z80, high level programming languages like C simply were not an option, you left too much performance on the table (not to mention BASIC which was easily 100x slower than handwritten assembly).
Forth was quite acceptable performance wise, but that's barely above a good macro assembler.
And after the 8-bitters, assembly coding on the Amiga was pure pleasure - also for large programs, since apart from the great 68k ISA the entire Amiga hardware and operating system was written to make assembly coding convenient (and even though C was much better on the 68k, most serious programs used a mix of C and assembly).
(also, while writing assembly code today isn't all that important, reading assembly code definitely is when looking at compiler output and trying to figure out why and how the compiler butchered my high level code).
> (also, while writing assembly code today isn't all that important, reading assembly code definitely is when looking at compiler output and trying to figure out why and how the compiler butchered my high level code).
Agreed - I wouldn't be able to write any x86 assembly without a bit of help, but having done some game reverse engineering I've learned enough to make sense of compiler generated code.
If you have a less-popular CPU, compilers today can be utter trash. GCC doesn't understand the TinyAVR core and emits insane assembly. Like iterating an array, instead of putting the array pointer in the Z register and using the atomic load-and-increment instructions, it will add to the pointer, read, subtract from the pointer, loop. It also uses the slower load instruction. Overall, looping over an array in C is 4 times slower than assembly, and consumes three times as much program space. Try examining the assembly from your next program, you'll probably be quite surprised at how awful it is.
I had to implement Morton ordering on this platform. The canonical C for this blows up to over 300 instructions per iteration. I unrolled the loop, used special CPU hardware and got the entire thing in under 100 instructions.
Compilers, even modern ones, are not magic and only understand CPUs popular enough to receive specific attention from compiler devs. If your CPU is unpopular, you're doing optimizations yourself.
Assembly doesn't matter to arduino script kiddies, but it's still quite important if you care at all about execution speed, binary size, resource usage.
I think writing assembly indeed offers no benefit for most developers. However, being able to read and understand assembly is generally useful.
Enables debugging binaries and crash dumps without complete source codes, like DLLs shipped with Windows or third-party DLLs. Allows to understand what compilers (both traditional and JIT) did to your source codes, this is useful when doing performance optimizations.
I never used it in production and yet learning it absolutely provided me with benefits. I didn't understand pointers until I spent a weekend learning assembly.
I've also heard the opinion that modern compilers are better at generating optimized code than someone writing assembly by hand. Not sure how true it is, but considering the unfathomable complexity of modern CPUs, it does feel believable.
As a low level performance guy I trust the compiler nowadays, especially with deep instruction pipelines. The compiler is beatable - a lot of the decisions are heuristic - but it takes a lot of work to beat it.
Last time I looked intel CPUs had like 1700 instructions. Every generation comes with an even more expanded ISA. I doubt that compilers use even a fraction of the ISA. Especially considering that binaries are often expected to run on a wide range of older CPUs. I know that there are intrinsic functions which provide access to some of the powerful, yet special purpose instructions. It is unrealistic to expect the compiler to make effective use of all the fancy instructions you paid for with your latest hardware upgrade.
If and only if someone has taken time to write specific optimizations for your specific CPU.
In embedded land, if your microcontroller is unpopular, you don't get much in the way of optimization. The assembly GCC generates is frankly hot steaming trash and an intern with an hour of assembly experience can do better. This is not in any way an exaggeration.
I've run into several situations where hand-optimized assembly is tens of times faster than optimized C mangled by GCC.
I do not trust compilers anymore unless it's specifically for x86_64, and only for CPUs made this decade
I've used "machine code" plenty of times in production as inline assembly encoded in other languages.
I vaguely recall ada inline assembly looking like function calls, with arguments that sometimes referenced high-level-language variables)
unrelated to that, I distinguish between machine code which is binary/hex, and assembly as symbolic assembler or macro assembler, which can actually have high level macros and other niceties.
And one thing I can say for sure. I took assembly language as my second computer course, and it definitely added a lifelong context as to how machines worked, what everything translated to and whether it was fast or efficient.
LOL. As a poor college student, I couldn't even afford an assembler. Programming my CoCo (Radio Shack Color Computer) had to be done either with the built-in BASIC, or by POKEing in machine codes for programs that I hand assembled. One of the nice things about Motorola (CoCo was based on MC6809E) assembly languages is that the processors were very regular and it was easy to remember the opcodes and operation structures.
A friend of mine who also had a CoCo wrote an assembler as a term project.
Sometimes you don't really want to write in assembler. Like loading a constant into a register for the AArch64. The instructions to do it are pretty wacky, and it's hard to see if you wrote the correct combination to load the value. Best to let the compiler do it for you (or use godbolt.org! to get the right mix). The same for floating point constants.
Once I got the code sequences for this right on my AArch64 code generator, I don't have to ever figure it out again!
Programming in assembly is slow. It takes a long time to make things that way; as Julia Ecklar sings, it's kind of like construction work with a toothpick for a tool. (https://www.youtube.com/watch?v=WZCs4Eyalxc) But that's also true of knitting (https://journal.stuffwithstuff.com/2025/05/30/consider-knitt...), crochet, plasterwork, childrearing, calligraphy, gardening, carving marble, hand-soldering electronics, watching sunrises, and solving crossword puzzles.
If you have a six-day deadline, probably it would be better to use a high-level language instead.
But, when you have time for them, all of these things are intrinsically rewarding. Not all the time! And not for everyone! But for some of us, some of the time, they can all be very enjoyable. And sometimes that slow effort can achieve a result that you can't get any other way.
I haven't written that much assembly, myself. Much less than you have. If I had to write everything in assembly for years, maybe I wouldn't enjoy it anymore. I've written a web server, a Tetris game, some bytecode interpreters, a threading library, a 64-byte VGA graphics demo, a sort of skeletal music synthesizer, and an interpreter for an object-oriented language with pattern-matching and multiple dispatch, as well as a couple of compilers in high-level languages targeting assembly or machine code. All of these were either 8086, ARM, RISC-V, i386, or amd64; I never had to suffer through 6809 or various microcontrollers.
Maybe most important, I've never written assembly code that someone else depended on working. Those programs I've mostly written in Python, which I regret now. It's much faster that way. However, I've found it useful in practice for debugging C and C++ programs.
I think that a farmer who says, "For the vast majority of consumers, gardening offers absolutely no benefit," is missing the point. It's not about easier access to parsley and chives. Similarly for an author who says, "For the vast majority of readers, solving crossword puzzles offers absolutely no benefit."
> as Julia Ecklar sings, it's kind of like construction work with a toothpick for a tool.
I was taught assembler
in my second year of school.
It's kinda like construction work —
with a toothpick for a tool.
So when I made my senior year,
I threw my code away,
And learned the way to program
that I still prefer today.
Now, some folks on the Internet
put their faith in C++.
They swear that it's so powerful,
it's what God used for us.
And maybe it lets mortals dredge
their objects from the C.
But I think that explains
why only God can make a tree.
For God wrote in Lisp code
When he filled the leaves with green.
The fractal flowers and recursive roots:
The most lovely hack I've seen.
And when I ponder snowflakes,
never finding two the same,
I know God likes a language
with its own four-letter name.
Now, I've used a SUN under Unix,
so I've seen what C can hold.
I've surfed for Perls, found what Fortran's for,
Got that Java stuff down cold.
Though the chance that I'd write COBOL code
is a SNOBOL's chance in Hell.
And I basically hate hieroglyphs,
so I won't use APL.
Now, God must know all these languages,
and a few I haven't named.
But the Lord made sure, when each sparrow falls,
that its flesh will be reclaimed.
And the Lord could not count grains of sand
with a 32-bit word.
Who knows where we would go to
if Lisp weren't what he preferred?
And God wrote in Lisp code
Every creature great and small.
Don't search the disk drive for man.c,
When the listing's on the wall.
And when I watch the lightning burn
Unbelievers to a crisp,
I know God had six days to work,
So he wrote it all in Lisp.
Yes, God had a deadline.
So he wrote it all in Lisp.
That's kind of how I feel about C. C is fun, because you get to see "everything"
But C is slow to create -- it is like using a toothpick
Writing from scratch is slow, and using C libraries also sucks. Certainly libc sucks, e.g. returning pointers to static buffers, global vars for Unicode, etc.
So yeah I have never written Assembly that anybody needs to work, but I think of it as "next level slow"
---
Probably the main case where C is nice is where you are working for a company that has developed high quality infrastructure over decades. And I doubt there is any such company in existence for Assembly
I have tried to convince people that ASM is reasonable as a first stage teaching language. The reputation as a nearly mystical art practiced by a few doesn't help. The thing is, instructions are simple. Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level.
It quickly becomes tedious to do large programs, not really hard, just unmanagable, which is precisely it should be taught as a first language. You learn how do do simple things and you learn why programming languages are used. You teach the problem that is being solved before teaching more advanced programming concepts that solve the problem.
The biggest problem with using ASM as a first language to teach beginners is that it is extremely tedious, error prone, and sensitive to details. It is also unstructured, it uses entirely different control flow primitives than any language they will learn in the future, meaning they will not be well prepared for learning a real language that does scale to programs more complex than a few additions and calling an OS output routine.
So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls?
It's a very nice exercise for understanding how a computer functions, and it has a clear role in education - I'm not arguing people shouldn't learn it at all. But I think it's a terrible first language to learn.
Because these are the primatives that are in use when programming in any language, and there is a benefit to learning the primatives before learning higher level abstractions. For instance we teach arithmetic before calculus.
I see lots of people become pretty helpless when their framework isn’t working as expected or abstraction becomes leaky. Most people don’t really need to know assembly in order to get past this, but the general intuition of “there is something underneath the subtraction that I could understand” is very useful.
> extremely tedious, error prone, and sensitive to details
I've taught people Python as their first language, and this was their exact opinion of it.
When you're an experienced programmer you tend to have a poor gauge of how newcomers internalize things. For people who are brand new it is basically all noise. We're just trying to gradually get them used to the noise. Getting used to the noise while also trying to figure out the difference between strings, numbers, booleans, lists, etc. is more difficult for newcomers than many people realize. Even the concept of scoping can sometimes be too high-level for a beginner, IME.
I like asm from the perspective that, its semantics are extremely simple to explain. And JMP (GOTO) maps cleanly from the flowchart model of programming that most people intuit first.
> So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls?
You can teach them how to implement function calls, variables and loops using assembly, to show them how they work under the hood and how they should be thankful for having simple if in their high level languages like C.
> it is extremely tedious, error prone, and sensitive to details.
That sounds like the perfect beginner language! If they survive that experience, they'll do very well in almost any type of programming, as it's mostly the same just a tiny bit less tedious. A bit like "hardening" but for programmers.
This is like learning to read by first being asked to memorize all the rules of grammar and being quizzed on them, or being forced to learn all the ins and outs of book binding and ink production.
It's tedious, unproductive, miserable.
There's very little reward for a lot of complexity, and the complexity isn't the "stimulating" complexity of thinking through a problem; it's complexity in the sense of "I put the wrong bit in the wrong spot and everything is broken with very little guidance on why, and I don't have the mental model to even understand".
There's a perfectly fine time to learn assembly and machine instructions, and they're useful skills to have - but they really don't need to be present at the beginning of the learning process.
---
My suggestion is to go even farther the other way. Start at the "I can make a real thing happen in the real world with code" stage as soon as possible.
Kids & adults both light up when they realize they can make motor turn, or an LED blink with code.
It's similarly "low level" in that there isn't much going on and they'll end up learning more about computers as machines, but much more satisfying and rewarding.
We teach math this way. Addition and subtraction. Then multiplication. Then division. Fractions. Once those are understood we start diversifying and teaching different techniques where these make up the building blocks, statistics, finance, algebra, etc.
It may put people off a programming career, but perhaps that is good. There are a lot of people who work in programming who don't understand the machines they use, who don't understand algorithms and data structures, they have no idea of the impact of latency, of memory use, etc. They're entire career is predicated on being able to never have to solve a problem that hasn't been solved in general terms already.
Starting with assembly makes it pretty clear why higher level languages had been invented. E.g. a speed run through computing:
- machine code
- assembly
- Lisp and Forth
- C
- Pascal
- maybe a short detour into OOP and functional languages
...but in the end, all you need to understand for programming computers are "sequences, conditions and loops" (that's what my computer club teacher used to say - still good advice).
> I have tried to convince people that ASM is reasonable as a first stage teaching language.
Unless you're teaching people preparing for engineering hardware perhaps, I think ASM is absolutely the wrong language for this. The first reason is that programming is about problem solving, not fiddling with the details of some particular architecture, and ASM is pretty bad at clearly expressing solutions in the language of the problem domain. Instead of programming in the language of the domain, you're busy flipping bits which are an implementation detail. It is really a language for interfacing with and configuring hardware.
The more insidious result is that teaching ASM will make an idol out of hardware by reinforcing the notion that computer science or programming are about computing devices. It is not. The computing device is totally auxiliary wrt subject matter. It is utterly indispensable practically, yes, but it is not what programming is concerned with per se. It is good for an astronomer to be able to operate his telescope well, but he isn't studying telescopes. Telescope engineers do that.
> The first reason is that programming is about problem solving, not fiddling with the details of some particular architecture, and ASM is pretty bad at clearly expressing solutions in the language of the problem domain. Instead of programming in the language of the domain, you're busy flipping bits which are an implementation detail.
"How do I use bits to represent concepts in the problem domain?" is the fundamental, original problem of computer science.
And to teach this, you use much simpler problems.
> ... reinforcing the notion that computer science or programming are about computing devices. It is not.
It is, however, about concepts like binary place-value arithmetic, and using numbers (addresses) as a means of indirection, and about using indirection to structure data, and about being able to represent the instructions themselves as data (such that they can be stored somewhere with the same techniques, even if we don't assume a Von Neumann machine), and (putting those two ideas together) about using a number as a way to track a position in the program, and manipulating that number to alter the flow of the program.
In second year university I learned computer organization more or less in parallel with assembly. And eventually we got to the point of seeing - at least in principle - how a basic CPU could be designed, with its basic components - an ALU, instruction decoder, bus etc.
Similarly:
> It is good for an astronomer to be able to operate his telescope well, but he isn't studying telescopes.
The astronomer is, however, studying light. And should therefore have a basic mental model of what a lens is, how lenses relate to light, how they work, and why telescopes need them.
Ooh, very much disagree with a lot of these assertions. The problem I always encounter when trying to teach programming is that students completely lack an understanding of how to imagine and model the state of the computational system in their heads. This leads to writing code that looks kinda like it should do what the student wants, but betrays the fact that they really don't understand what the code actually means.
In order to successfully program a solution to a problem, it is necessary to understand the system you are working with. A machine-level programming language cuts through the squishiness of that and presents a discrete and concrete system whose state can be fully explained and understood without difficulty. The part where it's all implementation details is the benefit here.
The best ISA for learning is probably the Motorola 68000, followed by some 8-bit CPUs (6502, 6809, Z80), also probably ARM1, although I never had to deal with it. I always thought that x86 assembly is ugly (no matter if Intel or AT&T).
> It quickly becomes tedious to do large programs
IME with modern tooling, assembly coding can be surprisingly productive. For instance I wrote a VSCode extension for 8-bit home computers [1], and dog-fooded a little demo with it [2], and that felt a lot more productive than back in the day with an on-device assembler (or even typing in machine code by numbers).
I think you can build environments that give immediate feedback and the ability to do real things quickly in ASM. I would still recommend moving swiftly on to something higher level as soon as it started to feel like a grind.
Sure, but learning an old ISA can leave you with a very very wrong idea about how modern processors work. Even x86 assembly paints a very misleading image of how modern processors actually work. For example, someone learning x86-64 assembly will likely believe all of the following:
- assembly instructions are executed in the order they appear in in the source code
- an x86 processor only has a handful of registers
- writing to a register is an instruction like any other and will take roughly the same time
- the largest registers on an x86 processor are 64-bit
I agree that M68k is nice, as are the 8-bit ones you mention. I just find it strange that you like Z80 and dislike x86 - they are fundamentally not that different and both are descended from 8080.
I started with Z-80 assembly, then BASIC, then 6502 assembly, then higher-level languages like C and perl, and I think the assembly gave me a useful foundation for what was going on under the hood. I'm not sure I'd even call assembly a "language" in the sense of the others. It has instructions, not statements, and there's really no syntax.
If I were teaching a general-interest programming course, I'd probably start with just a bit of BASIC to introduce a few broad concepts like variables and looping, then a little assembly to say, "And this is what's going on when you do those things," and then move up the chain. Then when they get to something like C and go to look at the assembly it produces for debugging, they'll at least be familiar with concepts like registers and branching. So not quite the order I happened to do it in, but similar.
I was a TA for an intro to assembly language course, which means I got my office hours full of all of the students who struggled with assembly language and had to work with them one-on-one to get them over their roadblocks to pass the class.
Assembly language is not a reasonable first programming language. There's just so many things about it that make it a poor choice for programming instruction.
Chiefly, assembly lacks structure. There's no such thing as variables. There's no such thing as functions. You can fake some of this stuff with convention, but if you make mistakes--and students in intro-to-programming will make mistakes--there is nothing that's going to poke you that you did something wrong, you just get the wrong result.
If you have a good macro assembler, it is only a little more difficult than C. There's just more to learn up front (things like calling conventions, register usage, etc...).
I wouldn't teach it first, but after a person knows the basics in another language, seeing how it all actually works can be fun.
I think in most CS programs, students do learn assembly early on, perhaps not as the first language, but definitely as a second language, as required by most Arch courses.
This almost feels like an argument that we should teach computer science via bare metal bootstrapping.
Start out at "here's your machine code. Let's understand how x86_64 gets started" and work your way up to "now you have the automation to compile Linux and a modern compiler".
Which would certainly have stops most of the way up for things we usually include.
Personally way back when, I first learned BASIC, then tried to learn C, but didn't get pointers, then learned ASM, and then pointers became obvious, and went back to C. If you're going to be using C or doing anything with hardware, learning ASM IMO is very useful just to understand how the machine really works.
assembly is a good first language if you have a simple instruction set or machine. When I saw new people learn java, easily the hardest initial bump to get over was "what the hell is public static void main(String[] args) ?" or "eclipse didn't build it for some reason"
Python is much easier to introduce someone to because there's no boilerplate and the tooling is very simple. Assembly on x86 machines is a royal PITA to set up, and you also need some kind of debugger to actively inspect the program counter and registers.
When I took Computer Organization & Architecture, they had us play around with MARIE[1] which really made assembly make sense to me. After that, I wrote an 8080 emulator and it made even MORE sense to me.
> Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level.
Indeed - you don't actually need to work on difficult tasks to get the intellectual benefit. Once you've properly understood what a computer is, you can absorb the ideas of SICP.
It's just as straightforward as in higher level languages, just not quite as interactive as interpreted languages, but I've never seen an "intro to programming" that started in a REPL even when using an interpreted language. Hello world is even shorter and simpler than most languages (in a modern OS environment).
16 bit x86 isn't that complicated and (IMO) still helpful in learning some of the more modern stuff. But I'd recommend starting with either 6502, or the 8080, which is like the 8 bit "grandparent" of x86.
Avoid:
- Z80: at least as a first language. Extended 8080 with completely different syntax, even more messy and unorthogonal than x86!
LD A,(HL) ;load A from address in HL register pair
LD A,(DE) ;load A from address in DE
LD B,(HL) ;load B from address in HL
LD B,(DE) ;invalid!
JP (HL) ;load program counter with contents of HL (*not* memory)
ADD A,B ;add B to A
ADC A,B ;add B to A with carry
SBC A,B ;subtract B from A with borrow
SUB B ;subtract B from A
OR B ;logical-or B into A
etc.
- RISC-V: an architecture designed by C programmers, pretty much exclusively as a target for compiling C to & omitting anything not necessary for that goal
For actually programming in machine code this understanding of the internal opcode structure isn't all that useful though, usually - without an assembler at hand - you had a lookup table with all possible assembly instructions on the left side, and the corresponding machine code bytes on the right side.
Programming by typing machine code into a hex editor is possible, but really only recommended as absolute fallback if there's no assembler at hand - mainly because you had to keep track of all global constant and subroutine entry addresses - e.g. the main thing that an assembler does for you, and you had to leave gaps at strategic locations so that it is possible to patch the code without having to move things around.
For the past year or so, a couple teen boys from my neighborhood come by on sunday afternoon for a couple hours of programming in python. I started very simply and built up with text based tasks, then showed them pygame.
I am thinking about showing them what is under the hood, that python itself is just a program. When I learned to program it was the late 70s, and trs-80s and apple-IIs were easy to understand at the machine code level.
I could recapitulate that experience for them, via an emulator, but that again just feels like an abstraction. I want them to have the bare-metal experience. But x86 is such a sprawling, complicated instruction set that it is very intimidating. Of course I'd stick to a simplified subset of the instructions, but even then, it seems like a lot more work to make output running on a PC vs on the old 8-bit machines where you write to a specific location and it shows up on the screen.
Buy them a copy of "Human Resource Machine" on Steam or (preferably since there's no DRM) Good Old Games. It's a gamified version of what writing machine language on the old 8 bit CPUs of yore was like. The puzzle challenge in HRM is authentic in the sense that it derives from the natural constraints of having a single accumulator and very simple instructions rather than unnaturally injected constraints like the Zachtronics games, which are good but I wouldn't recommend as a learning tool.
You could try the thing that made it click for me, long after x86 was dominant.
Show them a CPU running on Logisim (or the like, such as the newer Digital) and show how when you plug a program into a ROM, it turns into wires lighting up and flipping gates/activating data lines/read registers etc.
ASM programming is fun. Machine code (as in what ASM encodes to) isn't scary, but it is extremely tedious to work with. I recommend the first part of Casey Muratori's Performance Aware Programming course if you want to feel that pain.
I think you need to do it in production to retain the knowledge. If you just do it as a hobby, then most people just give up at certain point because there is no point to bang your head on the wall for nothing. You need to have a real problem to solve to go a long way.
My 23+ year experience in computer science and programming is a zebra of black-or-white moments. For the most time, things are mostly obscure, complicated, dark and daunting. Until suddenly you stumble upon a person who can explain those in simple terms, focus on important bits. You then can put this new knowledge into a well-organized hierarchy in your head and suddenly become wiser and empowered.
"Writing documentation", "talking at conferences", "chatting at a cooler", "writing to a blog" and all the other discussions from twitter to mailing lists - are all about trying to get some ideas and understanding from one head into another, so more people can get elucidated and build further.
And oh my how hard is that. We are lucky to sometimes have enlightenment through great RTFMs.
I started building a Forth recently, but decided that instead of interpreter or transpiler or whatever, I'd map to bytes in memory and just straight execute them.
This non-optimising JIT has been far, far easier than all the scary articles and comments I've seen led me to believe.
I'm already in the middle of making it work on both Aarch64 and RISC-V, a couple weeks in.
We did a similar approach back in the day, when going through the Tiger language[0], on the Java version.
Our approach was to model the compiler IR into Assembly macros, and follow the classical UNIX compiler build pipeline, thus even though it wasn't the most performant compiler in the world, we could nonetheless enjoy having our toy compiler generate real executables in the end.
I did this for WebAssembly WAT (an IR that is syntactically similar to lisp) by mapping the AST for my lisp more or less directly to the WAT IR, then emitting the bytecode from there. It was pretty fun.
I mean, it’s not hard as such, the encodings of some instruction sets are just ass, with 32- and 64-bit x86 as the foremost example and Thumb-2 not far behind it. Also, if you’re dynamically patching existing code, you’ll have to contend with both modern OSes (especially “hardening” patches thereto) making your life harder in bespoke incompatible ways (see: most of libffi) and modern CPUs being very buggy around self-modifying code. Other than that, it just takes quite a bit of tedious but straightforward work to get anywhere.
Oh, it's still a while off that. I do plan to make it public at some point, but when I'm actually happy the code isn't completely vomit.
But for a simple taste, the push to stack function currently looks like this. (All the emit stuff just writes bytes into a mmap that gets executed later.)
Machine code isn't scary, but its nature is severely misunderstood.
Skipping over the bundling of instructions into code blocks, the next logical construct are functions. These have references to code and data in memory; if you want to relocate functions around in memory you introduce the concept of relocations to annotate these references and of a linker to fix them to a particular location.
But once the linker has done its job, the function is no longer relocatable, you can't move it around... or that is what someone sane might say.
If you can undo the work of the linker, you can extract relocatable functions from executables. These functions can then be reused into new executables, without decompiling them first; after all, if what you've extracted is equivalent to the original relocatable function, you can do the same things than it.
Repeat this process over the entire executable and you're stripped it for parts, ready to be put back together with the linker. Change some parts and you have the ability to modify it as if you're replacing object files, instead of binary patching it in place with all the constraints that comes with it.
Machine code is like Lego bricks, it just takes a rather unconventional point of view (and quite a bit of time to perfect the art of delinking) to realize it.
I taught myself to program on an 8-bit BBC micro-computer in the mid-80s by typing in BASIC listings. I understood BASIC quite well, and could write my own structured BASIC programs, but machine code was always a bit out-of-reach. I would try to read books that started by demonstrating how to add, subtract etc, but I couldn’t see how that could build up to more complicated stuff that I could do in BASIC, like polling for input, or playing sounds, or drawing characters on the screen. Only once I got an advanced users guide and discovered the operating system commands, then it started to click with me - the complicated stuff was just arranging all the right data in the right bits of memory or registers, then (essentially) calling a particular OS command and saying ‘here’s the data you want’.
Yeah the issue is that the pedagogy doesn’t make it clear how to bridge the “calculator” with the OS stuff. I had this issue when I was a kid. How does adding eventually make something draw on the screen? Of course, it doesn’t, you need some hardware or OS specific information
It wasn't until I read Petzold's CODE that this stuff, especially the role of the the motherboard bridging processing, memory and I/O and what an OS is for, that it started to click for me.
But if this doesn't satisfy your curiosity, you might realize this is just pushing the magic blackbox/question mark a little further down the chain
How does the OS and the hardware draw on the screen, actually? All they have is also just calculator stuff, super basic primitives. You can't even do loops in hardware, or even real branches (hardware always "executes both sides" of a branch at once)
Anyways, if you keep digging long enough you eventually end up finding this XKCD https://xkcd.com/435/ =)
It's really interesting to see what people focus on when learning new things. Instruction encoding is something I would consider arcane knowledge, except that it isn't really useful; if you need to write an assembler or a disassembler, you can always look it up, but otherwise assembler instructions is basically all you need. Focusing on the nuances of a specific architecture's encoding is like people studying arithmetic instead of algebra and saying they now understand "math"; like, yes, a little, but there's so much you don't even know you don't know.
I'm absolutely not criticizing the author here, machine code can absolutely be beautiful and I love the "it isn't scary" sentiment, it just surprised me how unique the focus is. In fact, I think this is the first time I've ever read a post on "low-level computer stuff isn't that hard" and it was about machine code rather than assembly.
Then again, I can absolutely see the appeal. Architectures are fun, and I remember myself designing ones all the time in childhood during summer vacation. (Yes, I know I'm autistic.) Seeing tradeoffs between variable-length and fixed-length, short and long instructions, how register count affects code simplicity and the available opcode space, etc. kind of gives you an intuitive understanding of why real-world architectures look the way they do.
In 1982, I programmed my ZX81 by converting assembly to hex by hand because BASIC was just too slow. I'd write my assembly on paper, convert it to hex using reference tables, then use a simple BASIC FOR loop to POKE the values into memory we'd reserved space for the machine code in a REM statement at a fixed position in memory.
When all the values were POKEd in, I'd save to tape and execute it with RAND USR 16514.
That memory address is permanently etched in my brain even now.
It wasn't good, bad or scary it was just what I had to do to make the programs I wanted to make.
I did the same thing, on the 48k Spectrum, a year or two later. I also remembered to add some NOPs between functions, to avoid me having to recalculate all the relative jump instructions if I made changes.
For me the 'scary' part of machine code was never the actual logic. It was always just staring at that wall of hex or mnemonics and feeling like I needed a secret decoder ring!
To me, it looks like some kind of complex tetris game. I guess we could maybe represent a program as such, with pieces for registers, instructions, etc.
Yet, the tooling we have is very terse, and textual.
I enjoyed having to reload everything from tape (compact cassette tape - ie the kind of thing you'd use with a home computer in the early eighties), after a crash due to my poor code. I think the term used then was "character building" ;)
One of my first C programs wrote straight into the BIOS memory (1989 iirc). The machine froze and refused to reboot. We had to remove the BIOS battery to reset the BIOS. Luckily, the battery wasn't soldered to the main board.
I can relate to you, OP.Sorry for off topic I want to share my experience about my journey of programming. When I started programming, I was introduced to the ideas of variables, conditions, loops, functions—regular programming constructs. But I didn't understand much of what was going on, how the computer worked, or anything beyond just the syntax. I used to wonder: when I start my PC, how does it even know where to begin? I often felt insecure and anxious about all these unknowns. I was trapped in tutorial hell, thinking that just gluing pieces of code together was enough. It made sense for a while, but eventually, I wanted to quit.
After some time, I searched online about how to improve, and people recommended learning data structures and algorithms (DSA). I didn’t know how to implement data structures on my own and struggled a lot—almost like going through hell. Nothing made sense. I couldn’t even get beyond linked lists.
Then I found a Reddit post saying I might have the wrong mental model. It said that even if you know some programming, without understanding how to think about structures and systems, you're stuck. I started searching for what 'mental models' meant, but due to my lack of experience, I didn’t find anything useful.
Later, I read a discussion on Hacker News about the book Structure and Interpretation of Computer Programs (SICP). One commenter explained how the book starts with the concept of data and procedures. That really clicked for me. I had never thought of computation as just transforming input data into output data. The model of:
Input → Computation → Output
made everything fall into place. This idea carries through all levels of programming—whether it's assembly, mid-level, or high-level languages. It’s the fundamental notion. You need basic constructs to steer data through transformations into useful outputs. Computation is essentially about transforming one form of information into another.
After that realization, everything started to make sense—assembly, high-level programming, even operating systems. It was one of the best ‘aha!’ moments of my life."
Information is omnipresent (this is just an intuition, not a claim). It serves as both input and output.
Computation—also known as a procedure, function, set of instructions, transformation, method, algorithm, or calculation.
In my early days, I ignored the fundamental notion of data and procedures. But eventually, it clicked:
Programs = Data + Instructions
Watch Feynman on computing—he even starts with the same concept of data, introducing computers as information processing systems. And processing requires algorithms (i.e., instructions or procedures).
Programming is simply writing instructions for the computer to perform computations.
A computer is just a machine for computing.
Computation is a general idea: a transformation of one form of information into another.
Machine code ceased to be scary, or at least mysterious, to me when I opened the rudimentary debugger on a TRS-80. It was really more of a monitor, and it showed the contents of a certain chunk of memory in the top half of the screen. I loaded a program I was working on into it, and began changing instructions in memory, using the assembler output as my guide, and jumping into the program to see what the effects were. After that the little lightbulb went off. Oh, these are just bytes in memory that correspond to CPU instructions, and the CPU just reads them off and executes the instructions.
This is the video I wished I had seen when I was a kid, feeling like assembly was a dark art that I was too dumb to be able to do. Later in life I did a ton of assembly professionally on embedded systems. But as a kid I thought I wasn’t smart enough. This idea is poison, thinking you’re not smart enough, and it ruins lives.
I always thought machine code was something only experts could understand. But after reading this article, I realized the basic concepts aren’t that complicated, it’s really just instructions, registers, and memory.
I feel like this has given me a clearer understanding when it comes to writing code.
When I was last working with machine code, I found capstone to be very useful. Even just reading the source was helpful for some of the conditionally present amd64 fields.
Oh, cool. A couple years ago I spent a few days disassembling a small x86-64 binary by hand. Getting familiar with the encoding was a lot of fun! The following reference was indispensable:
Ok, what about VLIW ASM? Have you ever seen Elbrus' ASM with predicated code, asynchronous Array Prefetch Buffer, rotating registers, DAM (hardware table to memory dependencies disambiguation), registers windows etc. It's really hard to start read this.
That is fun. But this one truly is enough: Turing Complete. You start with boolean logic gates and progressively work your way up to building your own processor, create your own assembly language, and use it to do things like solve mazes and more. Super duper fun
> But what if we want to represent a number larger than 12 bits? Well, the add instruction doesn't let us represent all such numbers; but setting sh to 1 lets us shift our number by 12 bits. So for example we can represent 172032172032 by leaving our 42 alone and setting sh to 1. This is a clever technique for encoding larger numbers in a small space.
This is whacky. So presumably adding with a 24-bit constant whose value isn't representable in this compressed 13-bit format would then expand to two add instructions? Or would it store a constant to a register and then use that? Or is there a different single instruction that would get used?
add_large_const:
lui a5,43
addi a5,a5,42
add a0,a0,a5
ret
Because there are only 32 bits in an instruction, you can't fit a whole 32-bit immediate into it. Contrast it with x86 which uses variable-length instructions (up to 15 bytes per instruction):
add_large_const:
lea eax, [rdi+176170] # this instruction takes 6 bytes
ret
P.S. Some people seem to be really puzzled by LEA instructions. It's intended use is to correspond to C's "dest = &base[offset]" which semantically is just "dest = base + offset", of course — but it allows one to express base and/or offset using available addressing modes.
The thing is: most programmers see assembly language generated by a compiler,
so no comment, and in optimised code with vector operations, it IS scary.
Well, machine code is scary. But like with many scary things, once you overcome your fears and get familiar with the thing, you realize that it is not that bad.
This is a tangent but yesterday I was just pondering the abstraction layer from machine code to assembly lexers to compilers to interpreted languages. Having been lucky enough to be born at a time to witness these shifts, it's so easy to forget what we used to think was normal.
The thought came to me when testing the new Jules agentic coding platform. It occured to me that we are just in another abstraction cycle, but like those before, it's so hard to see the shift when everything is shifting.
My conclusion? There will be non-AI coders, but they will be as rare as C programmers before we realize it.
I think this article is missing a major point, or perhaps should be titled "Some Non-Scary Machine Code Isn't Scary". It argues that machine code isn't scary, by building a one-to-one mapping from machine code to assembly code, and then taking it as given that assembly code isn't scary. But it uses two examples -- 32-bit ARM and x86-64 -- where this one-to-one mapping isn't valid. When in Thumb mode for (some flavors of) ARM, even when you know you're in thumb mode, instructions can be a mix of 16 and 32 bits. And in x86 world, of course, instructions can be a wide range of widths. What that means is that if you're given a chunk of memory that is known to contain executable instructions... you /can't/ build a one-to-one mapping to assembly without knowing where all of the entry points are. For well-formed code you can often exclude almost all possible entry points as invalid, and maybe even end up with only a single one... but it's perfectly possible (and quite fun) to write machine code that has valid, different behavior for different entry points to the same byte sequence. There's no way to reduce this type of machine code to meaningful assembly, and it should be considered scary.
Reading this thread leaves me with the impression that most posters advocating learning assembly language have never had to use it in a production environment. It sucks!
For the overwhelming majority of programmers, assembly offers absolutely no benefit. I learned (MC6809) assembly after learning BASIC. I went on to become an embedded systems programmer in an era where compilers were still pretty expensive, and I worked for a cheapskate. I wrote an untold amount of assembly for various microcontrollers over the first 10 years of my career. I honestly can't say I got any more benefit out of than programming in C; it just made everything take so much longer.
I once, for a side gig, had to write a 16-bit long-division routine on a processor with only one 8-bit accumulator. That was the point at which I declared that I'd never write another assembly program. Luckily, by then gcc supported some smaller processors so I could switch to using Atmel AVR series.
I've written assembly in a production environment. I love it and wish I could do more.
But the context where I'm doing it is very different from the context where you had to write a division routine from scratch! We never use assembly where a higher-level language would be good enough. It's only used for things that can't be written in C at all, either because it needs an instruction that the C compiler won't emit, or it involves some special calling convention that C can't express.
However, I read assembly in production all the time. Literally every day on the job. It's absolutely essential for crashes that won't reproduce locally, issues caused by compiler bugs, or extremely sensitive performance work. Now, lots of programmers very rarely have to deal with those sorts of things, but when it comes up, they'll be asking for help from the ones who know this stuff.
+1 on reading.
I hardly consider myself an expert ARM ASM programmer (or even an amateur...), but a baseline level of how to read it even if you have to look up a bunch of instructions every time can be super useful for performance work, especially if you have the abstract computer engineering know how to back it up.
For example, it turns out that gcc 7.3 (for arm64) doesn't optimize
the same as
!
The former was compiled into a branchless set of instructions, while the latter had a branch!
1 reply →
Just curious, what kind of work do you do? Sounds like SRE in FAANG that deals with production systems. I work as a DE and the lowest level thing I have to read is JVM dump from spark. Man I envy you.
2 replies →
> I once, for a side gig, had to write a 16-bit long-division routine on a processor with only one 8-bit accumulator. That was the point at which I declared that I'd never write another assembly program.
This is exactly the kind of job I'd enjoy! A perfectly doable technical challenge with clear requirements. Some people like solving Sudoku puzzles, I like solving programming puzzles.
I guess I'm just not "the overwhelming majority of programmers".
> doable technical challenge with clear requirements
That's a Project Management issue, not an implementation concern.
In my case, there was no requirement that said "use 16-bit long division." However, we had committed to a particular processor family (MC68HC05), and the calculation precision required 16-bit math. IIRC, there was a compiler available, but it cost more than the rest of the project and the code it produced wouldn't have fit into the variant of the processor that I was using anyway.
The actual requirement would have looked more like "detect a 0.1% decrease in signal that persists for 10 seconds, then do X."
2 replies →
> the kind of job I'd enjoy
I feel the same way, but I also can't help but imagine the boss jumping up and down and throwing chairs and screaming "how can you not be done yet? You're a programmer and this is a program and it's been three _hours_ already".
I totally agree. I read and commented the source code of Woz's SWEET16 and it was a blast to fully understand it.
But of course, might not be that rosy if under great time constraints.
I think the majority of programmers would enjoy it, but most would first need to pick an ISA (something older is probably going to be more approachable for beginners), learn enough about it to understand basic arithmetic instructions, learn enough about the dev tools to be able to assemble, link, and execute their code, etc.
For most folks, that's going to be a couple days of prep work before they can get to the fun part of solving the puzzle.
"I guess I'm just not the "overwhelming majority of programmers"."
The "overwhelming" majority of programmers may be underwhelming
Some readers may be unimpressed by programmers who complain about and criticise assembly language, e.g., claiming it offers "no benefit" to others, especially when no one is forcing these programmers to use it
I did a lot of assembler programming before discovering C. I learned C in maybe an hour because of that.
Not knowing assembler means programmers have a bit of a blind spot towards what are expensive things to do in C vs what generates the best code.
For example, debugging a program sometimes requires looking at the generated assembler. Recently I was wondering why my deliberate null pointer dereference wasn't generating an exception. Looking at the assembler, there were no instructions generated for it. It turns out that since a null pointer dereference was undefined behavior, the compiler didn't need to generate any instructions for it.
I build web applications that run on top of databases, web servers and frameworks.
I do need to understand how indexes in db engine work, I need to understand there might be socket exhaustion in the system, I do need to understand how my framework allocates data on heap vs stack.
Having to drop to instructions that is for web servers, db, frameworks developers not for me to do. I do have a clue how low level works but there is no need for me.
That is part where parent poster is correct there are better ways for developers to spend time on - trust your database, web servers and framework and learn how those work in depth you can skip asembler, because all of those will take a lot of time anyway and most likely those are the ones you should/can tweak to fix performance not assembler.
> since a null pointer dereference was undefined behavior, the compiler didn't need to generate any instructions for it.
I deeply hate this attitude in modern compiler design.
2 replies →
The issue is it's a moving target. What was expensive yesterday could be fast today based on compiler optimizations (and potentially vice versa).
Further, changes in the ISA can open up gains in performance that weren't available in yesteryear. An example of this would be SIMD instruction usage.
It's not a bad idea to know enough assembly language to understand why code is slow. However, the general default should be to avoid writing it. Your time would be better spent getting a newer version of your compiler and potentially enabling things like PGO.
> most posters advocating learning assembly language have never had to use it in a production environment... For the overwhelming majority of programmers, assembly offers absolutely no benefit.
I don't follow. Why should assembly have to be useful or pleasant in a production environment, for learning it to be useful?
I was taught a couple different flavours of assembly in university, and I found it quite useful for appreciating what the machine actually does. Certainly more so than C. Abstractions do ultimately have to be rooted in something.
You and the post you commented on display both a valid point. If we're talking about using assembly as a broad general purpose programming environment that would be a mess (which is precisely why it has no broad adoption). When we talk about assembly as a niché special purpose solution we would come to a different conclusion, coincidentally this is where assembly is still used today: environments where we need highly optimized code.
Your point about education is orthogonal to the point made. I agree with you that learning assembly can be a good way to teach people how computers work on a low level, but that has nothing to do with whether it is useful as a skill to learn.
As someone teaching similar things at the university level to a non-tech audience I have to always carefully wheigh how much "practically useless" lessons a typical art student can stomach. And which kind of lesson will just deter them, potentially forever.
1 reply →
Is it useful to learn bagpipes? I guess learning for its own sake is good, but if you want to join a band, guitar or keyboards are going to be a better bet and learning bagpipes first isn't going to do much for you.
12 replies →
> Reading this thread leaves me with the impression that most posters advocating learning assembly language have never had to use it in a production environment. It sucks!
It absolutely sucks. But it's not scary. In my world (Zephyr RTOS kernel) I routinely see people go through all kinds of contortions to build abstractions around what are actually pretty straightforward hardware interfaces. Like, here's an interrupt controller with four registers. And here's a C API in the HAL with 28 functions and a bunch of function pointer typedefs and handler mechanics you're supposed to use to talk to it. Stuff like that.
It's really common to see giant abstractions built around things that could literally be two-instruction inline assembly blocks. And the reason is that everyone is scared of "__asm__".
This exactly. If you are doing embedded programming, direct register access and manipulation is often a far, far superior option, and you don’t have to be some kind of “assembly sensei” to do it if you just have a very basic idea of how things work. It doesn’t mean you write programs in assembly… it means when you are needing to do something that the hardware is going to do for you anyway, you know how to ask for it directly without having to load a 2Kloc library. This is especially true when using python or JS bytecode on the MCU. Actually, using python with assembly is really the best of both worlds in many cases.
Yeah, but doesn't the Zephyr device tree abstraction actually expect you to do that? I mean, I appreciate the elegance and the desire for portability, but all I could think of as I read those docs was "here's a couple months of work for something that should take ten minutes."
1 reply →
Most of us do not have the chance to use it in production. I think that's where the fancy came from.
We are also getting burned out by the modern Agile web/data/whatever development scene and would like to drill really deep into one specific area without stakeholders breathing down our necks every few hours, which assembly programming conveniently provides.
I also consider the grit (forced or voluntary) to be a bath of fire which significantly improved two important things - the programmer's understanding of the system, and the programmer's capability to run low level code in his brain. Is it suffering? Definitely, but this is a suffering that bring technical prowess.
Most of us do not have the privilege to suffer properly. Do you prefer to suffer from incomplete documentation, very low level code and banging your head on a wall for tough technical problems, or do you prefer to suffer from incomplete documentation, layers and layers of abstraction, stakeholders changing requirements every day and actually know very little about technical stuffs? I think it is an easy choice, at least for me. If there is an assembly language / C job that is willing to take me in, I'll do it in half of the salary I'm earning.
I started my career in assembly and it's reduced over time. Towards the end of the gamedev work I was still reading a lot of assembly but no longer writing it (using intrinsics instead). It was definitely a lot slower to write.
But there are a number of things we did that are not available or difficult in C:
- Guaranteed tail calls
- Returning multiple values without touching memory
- using the stack pointer as a general purpose pointer for writing to memory
- Changing the stack pointer to support co-routimes
- Using our own register / calling convention (e.g. setting aside a register to be available to all routines
- Unpicking the stack to reduce register setup for commonly used routines or fast longjmps
- VM "jump tables" without requiring an indirection to know where to jump to
On 8-bit home computer CPUs like the 6502 or Z80, high level programming languages like C simply were not an option, you left too much performance on the table (not to mention BASIC which was easily 100x slower than handwritten assembly).
Forth was quite acceptable performance wise, but that's barely above a good macro assembler.
And after the 8-bitters, assembly coding on the Amiga was pure pleasure - also for large programs, since apart from the great 68k ISA the entire Amiga hardware and operating system was written to make assembly coding convenient (and even though C was much better on the 68k, most serious programs used a mix of C and assembly).
(also, while writing assembly code today isn't all that important, reading assembly code definitely is when looking at compiler output and trying to figure out why and how the compiler butchered my high level code).
> (also, while writing assembly code today isn't all that important, reading assembly code definitely is when looking at compiler output and trying to figure out why and how the compiler butchered my high level code).
Agreed - I wouldn't be able to write any x86 assembly without a bit of help, but having done some game reverse engineering I've learned enough to make sense of compiler generated code.
To add to that, there is a reason why even all modern JITs also have ways to look into generated code.
Anyone curious how their JVM, CLR, V8, ART, Julia,.... gets massaged into machine code only needs to learn about the related tools on the ecosystem.
Some of them are available on online playgrounds like Compiler Explorer, Sharpio,....
> the entire Amiga hardware and operating system was written to make assembly coding convenient
I am curious what specific examples do you have of the HW and OS being made/written to make ASM convenient?
2 replies →
If you have a less-popular CPU, compilers today can be utter trash. GCC doesn't understand the TinyAVR core and emits insane assembly. Like iterating an array, instead of putting the array pointer in the Z register and using the atomic load-and-increment instructions, it will add to the pointer, read, subtract from the pointer, loop. It also uses the slower load instruction. Overall, looping over an array in C is 4 times slower than assembly, and consumes three times as much program space. Try examining the assembly from your next program, you'll probably be quite surprised at how awful it is.
I had to implement Morton ordering on this platform. The canonical C for this blows up to over 300 instructions per iteration. I unrolled the loop, used special CPU hardware and got the entire thing in under 100 instructions.
Compilers, even modern ones, are not magic and only understand CPUs popular enough to receive specific attention from compiler devs. If your CPU is unpopular, you're doing optimizations yourself.
Assembly doesn't matter to arduino script kiddies, but it's still quite important if you care at all about execution speed, binary size, resource usage.
I think writing assembly indeed offers no benefit for most developers. However, being able to read and understand assembly is generally useful.
Enables debugging binaries and crash dumps without complete source codes, like DLLs shipped with Windows or third-party DLLs. Allows to understand what compilers (both traditional and JIT) did to your source codes, this is useful when doing performance optimizations.
I write mobile apps for living (mostly Java/Kotlin, a little bit of Flutter/RN) so yeah agree assembly is practically useless for professional work.
But for tinkering (e.g writing GBA/NES games), hell why not? It's fun.
I never used it in production and yet learning it absolutely provided me with benefits. I didn't understand pointers until I spent a weekend learning assembly.
As someone that has spent some time in the 8 and 16 bit demoscene, I used my share of Z80, 80x86 and 68000.
It is all a matter of having high quality macro assemblers, and people that actually care to write structured documented code in Assembly.
When they don't care, usually not even writing in C and C++ will save the kind of code they write.
I've also heard the opinion that modern compilers are better at generating optimized code than someone writing assembly by hand. Not sure how true it is, but considering the unfathomable complexity of modern CPUs, it does feel believable.
As a low level performance guy I trust the compiler nowadays, especially with deep instruction pipelines. The compiler is beatable - a lot of the decisions are heuristic - but it takes a lot of work to beat it.
Last time I looked intel CPUs had like 1700 instructions. Every generation comes with an even more expanded ISA. I doubt that compilers use even a fraction of the ISA. Especially considering that binaries are often expected to run on a wide range of older CPUs. I know that there are intrinsic functions which provide access to some of the powerful, yet special purpose instructions. It is unrealistic to expect the compiler to make effective use of all the fancy instructions you paid for with your latest hardware upgrade.
3 replies →
If and only if someone has taken time to write specific optimizations for your specific CPU.
In embedded land, if your microcontroller is unpopular, you don't get much in the way of optimization. The assembly GCC generates is frankly hot steaming trash and an intern with an hour of assembly experience can do better. This is not in any way an exaggeration.
I've run into several situations where hand-optimized assembly is tens of times faster than optimized C mangled by GCC.
I do not trust compilers anymore unless it's specifically for x86_64, and only for CPUs made this decade
1 reply →
I've used "machine code" plenty of times in production as inline assembly encoded in other languages.
I vaguely recall ada inline assembly looking like function calls, with arguments that sometimes referenced high-level-language variables)
unrelated to that, I distinguish between machine code which is binary/hex, and assembly as symbolic assembler or macro assembler, which can actually have high level macros and other niceties.
And one thing I can say for sure. I took assembly language as my second computer course, and it definitely added a lifelong context as to how machines worked, what everything translated to and whether it was fast or efficient.
LOL. As a poor college student, I couldn't even afford an assembler. Programming my CoCo (Radio Shack Color Computer) had to be done either with the built-in BASIC, or by POKEing in machine codes for programs that I hand assembled. One of the nice things about Motorola (CoCo was based on MC6809E) assembly languages is that the processors were very regular and it was easy to remember the opcodes and operation structures.
A friend of mine who also had a CoCo wrote an assembler as a term project.
Sometimes you don't really want to write in assembler. Like loading a constant into a register for the AArch64. The instructions to do it are pretty wacky, and it's hard to see if you wrote the correct combination to load the value. Best to let the compiler do it for you (or use godbolt.org! to get the right mix). The same for floating point constants.
Once I got the code sequences for this right on my AArch64 code generator, I don't have to ever figure it out again!
This post was very helpful when I tried to figure it out: https://dougallj.wordpress.com/2021/10/30/bit-twiddling-opti...
1 reply →
I expect a sufficiently good macro assembler should be able to do it as well.
1 reply →
Programming in assembly is slow. It takes a long time to make things that way; as Julia Ecklar sings, it's kind of like construction work with a toothpick for a tool. (https://www.youtube.com/watch?v=WZCs4Eyalxc) But that's also true of knitting (https://journal.stuffwithstuff.com/2025/05/30/consider-knitt...), crochet, plasterwork, childrearing, calligraphy, gardening, carving marble, hand-soldering electronics, watching sunrises, and solving crossword puzzles.
If you have a six-day deadline, probably it would be better to use a high-level language instead.
But, when you have time for them, all of these things are intrinsically rewarding. Not all the time! And not for everyone! But for some of us, some of the time, they can all be very enjoyable. And sometimes that slow effort can achieve a result that you can't get any other way.
I haven't written that much assembly, myself. Much less than you have. If I had to write everything in assembly for years, maybe I wouldn't enjoy it anymore. I've written a web server, a Tetris game, some bytecode interpreters, a threading library, a 64-byte VGA graphics demo, a sort of skeletal music synthesizer, and an interpreter for an object-oriented language with pattern-matching and multiple dispatch, as well as a couple of compilers in high-level languages targeting assembly or machine code. All of these were either 8086, ARM, RISC-V, i386, or amd64; I never had to suffer through 6809 or various microcontrollers.
Maybe most important, I've never written assembly code that someone else depended on working. Those programs I've mostly written in Python, which I regret now. It's much faster that way. However, I've found it useful in practice for debugging C and C++ programs.
I think that a farmer who says, "For the vast majority of consumers, gardening offers absolutely no benefit," is missing the point. It's not about easier access to parsley and chives. Similarly for an author who says, "For the vast majority of readers, solving crossword puzzles offers absolutely no benefit."
So I don't think assembly sucks.
> as Julia Ecklar sings, it's kind of like construction work with a toothpick for a tool.
1 reply →
That's kind of how I feel about C. C is fun, because you get to see "everything"
But C is slow to create -- it is like using a toothpick
Writing from scratch is slow, and using C libraries also sucks. Certainly libc sucks, e.g. returning pointers to static buffers, global vars for Unicode, etc.
So yeah I have never written Assembly that anybody needs to work, but I think of it as "next level slow"
---
Probably the main case where C is nice is where you are working for a company that has developed high quality infrastructure over decades. And I doubt there is any such company in existence for Assembly
2 replies →
yeah, it's not _scary_. It's just tedious.
I have tried to convince people that ASM is reasonable as a first stage teaching language. The reputation as a nearly mystical art practiced by a few doesn't help. The thing is, instructions are simple. Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level.
It quickly becomes tedious to do large programs, not really hard, just unmanagable, which is precisely it should be taught as a first language. You learn how do do simple things and you learn why programming languages are used. You teach the problem that is being solved before teaching more advanced programming concepts that solve the problem.
The biggest problem with using ASM as a first language to teach beginners is that it is extremely tedious, error prone, and sensitive to details. It is also unstructured, it uses entirely different control flow primitives than any language they will learn in the future, meaning they will not be well prepared for learning a real language that does scale to programs more complex than a few additions and calling an OS output routine.
So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls?
It's a very nice exercise for understanding how a computer functions, and it has a clear role in education - I'm not arguing people shouldn't learn it at all. But I think it's a terrible first language to learn.
Because these are the primatives that are in use when programming in any language, and there is a benefit to learning the primatives before learning higher level abstractions. For instance we teach arithmetic before calculus.
I see lots of people become pretty helpless when their framework isn’t working as expected or abstraction becomes leaky. Most people don’t really need to know assembly in order to get past this, but the general intuition of “there is something underneath the subtraction that I could understand” is very useful.
8 replies →
> extremely tedious, error prone, and sensitive to details
I've taught people Python as their first language, and this was their exact opinion of it.
When you're an experienced programmer you tend to have a poor gauge of how newcomers internalize things. For people who are brand new it is basically all noise. We're just trying to gradually get them used to the noise. Getting used to the noise while also trying to figure out the difference between strings, numbers, booleans, lists, etc. is more difficult for newcomers than many people realize. Even the concept of scoping can sometimes be too high-level for a beginner, IME.
I like asm from the perspective that, its semantics are extremely simple to explain. And JMP (GOTO) maps cleanly from the flowchart model of programming that most people intuit first.
5 replies →
> So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls?
You can teach them how to implement function calls, variables and loops using assembly, to show them how they work under the hood and how they should be thankful for having simple if in their high level languages like C.
14 replies →
> it is extremely tedious, error prone, and sensitive to details.
That sounds like the perfect beginner language! If they survive that experience, they'll do very well in almost any type of programming, as it's mostly the same just a tiny bit less tedious. A bit like "hardening" but for programmers.
2 replies →
So much this.
This is like learning to read by first being asked to memorize all the rules of grammar and being quizzed on them, or being forced to learn all the ins and outs of book binding and ink production.
It's tedious, unproductive, miserable.
There's very little reward for a lot of complexity, and the complexity isn't the "stimulating" complexity of thinking through a problem; it's complexity in the sense of "I put the wrong bit in the wrong spot and everything is broken with very little guidance on why, and I don't have the mental model to even understand".
There's a perfectly fine time to learn assembly and machine instructions, and they're useful skills to have - but they really don't need to be present at the beginning of the learning process.
---
My suggestion is to go even farther the other way. Start at the "I can make a real thing happen in the real world with code" stage as soon as possible.
Kids & adults both light up when they realize they can make motor turn, or an LED blink with code.
It's similarly "low level" in that there isn't much going on and they'll end up learning more about computers as machines, but much more satisfying and rewarding.
3 replies →
"is that it is extremely tedious, error prone, and sensitive to details. It is also unstructured,"
That's why it's such an important first language! Pedagogically it's the foundation motivating all the fancy things languages give you.
You don't teach a kid to cut wood with a table saw. You give them a hand saw!
5 replies →
Controversial opinion but we should be teaching new programmers how a CPU works and not hand-wave the physical machine away to the cloud.
Not doing this is how you get Electron.
We teach math this way. Addition and subtraction. Then multiplication. Then division. Fractions. Once those are understood we start diversifying and teaching different techniques where these make up the building blocks, statistics, finance, algebra, etc.
It may put people off a programming career, but perhaps that is good. There are a lot of people who work in programming who don't understand the machines they use, who don't understand algorithms and data structures, they have no idea of the impact of latency, of memory use, etc. They're entire career is predicated on being able to never have to solve a problem that hasn't been solved in general terms already.
3 replies →
Starting with assembly makes it pretty clear why higher level languages had been invented. E.g. a speed run through computing:
- machine code
- assembly
- Lisp and Forth
- C
- Pascal
- maybe a short detour into OOP and functional languages
...but in the end, all you need to understand for programming computers are "sequences, conditions and loops" (that's what my computer club teacher used to say - still good advice).
4 replies →
> I have tried to convince people that ASM is reasonable as a first stage teaching language.
Unless you're teaching people preparing for engineering hardware perhaps, I think ASM is absolutely the wrong language for this. The first reason is that programming is about problem solving, not fiddling with the details of some particular architecture, and ASM is pretty bad at clearly expressing solutions in the language of the problem domain. Instead of programming in the language of the domain, you're busy flipping bits which are an implementation detail. It is really a language for interfacing with and configuring hardware.
The more insidious result is that teaching ASM will make an idol out of hardware by reinforcing the notion that computer science or programming are about computing devices. It is not. The computing device is totally auxiliary wrt subject matter. It is utterly indispensable practically, yes, but it is not what programming is concerned with per se. It is good for an astronomer to be able to operate his telescope well, but he isn't studying telescopes. Telescope engineers do that.
> The first reason is that programming is about problem solving, not fiddling with the details of some particular architecture, and ASM is pretty bad at clearly expressing solutions in the language of the problem domain. Instead of programming in the language of the domain, you're busy flipping bits which are an implementation detail.
"How do I use bits to represent concepts in the problem domain?" is the fundamental, original problem of computer science.
And to teach this, you use much simpler problems.
> ... reinforcing the notion that computer science or programming are about computing devices. It is not.
It is, however, about concepts like binary place-value arithmetic, and using numbers (addresses) as a means of indirection, and about using indirection to structure data, and about being able to represent the instructions themselves as data (such that they can be stored somewhere with the same techniques, even if we don't assume a Von Neumann machine), and (putting those two ideas together) about using a number as a way to track a position in the program, and manipulating that number to alter the flow of the program.
In second year university I learned computer organization more or less in parallel with assembly. And eventually we got to the point of seeing - at least in principle - how a basic CPU could be designed, with its basic components - an ALU, instruction decoder, bus etc.
Similarly:
> It is good for an astronomer to be able to operate his telescope well, but he isn't studying telescopes.
The astronomer is, however, studying light. And should therefore have a basic mental model of what a lens is, how lenses relate to light, how they work, and why telescopes need them.
1 reply →
Ooh, very much disagree with a lot of these assertions. The problem I always encounter when trying to teach programming is that students completely lack an understanding of how to imagine and model the state of the computational system in their heads. This leads to writing code that looks kinda like it should do what the student wants, but betrays the fact that they really don't understand what the code actually means.
In order to successfully program a solution to a problem, it is necessary to understand the system you are working with. A machine-level programming language cuts through the squishiness of that and presents a discrete and concrete system whose state can be fully explained and understood without difficulty. The part where it's all implementation details is the benefit here.
6 replies →
IMO It depends a lot on the assembly flavour.
The best ISA for learning is probably the Motorola 68000, followed by some 8-bit CPUs (6502, 6809, Z80), also probably ARM1, although I never had to deal with it. I always thought that x86 assembly is ugly (no matter if Intel or AT&T).
> It quickly becomes tedious to do large programs
IME with modern tooling, assembly coding can be surprisingly productive. For instance I wrote a VSCode extension for 8-bit home computers [1], and dog-fooded a little demo with it [2], and that felt a lot more productive than back in the day with an on-device assembler (or even typing in machine code by numbers).
[1] https://marketplace.visualstudio.com/items?itemName=floooh.v...
[2] https://floooh.github.io/kcide-sample/kc854.html?file=demo.k...
Oh nice, I was talking just yesterday how I liked chips as a programming paradigm.
I agree about tooling, I made a pacman game in a dcpu16 emulator in a couple of days.
I experimented with a fantasy console idea using an in-browser assembler as well. https://k8.fingswotidun.com/static/ide/
I think you can build environments that give immediate feedback and the ability to do real things quickly in ASM. I would still recommend moving swiftly on to something higher level as soon as it started to feel like a grind.
Sure, but learning an old ISA can leave you with a very very wrong idea about how modern processors work. Even x86 assembly paints a very misleading image of how modern processors actually work. For example, someone learning x86-64 assembly will likely believe all of the following:
- assembly instructions are executed in the order they appear in in the source code
- an x86 processor only has a handful of registers
- writing to a register is an instruction like any other and will take roughly the same time
- the largest registers on an x86 processor are 64-bit
10 replies →
I agree that M68k is nice, as are the 8-bit ones you mention. I just find it strange that you like Z80 and dislike x86 - they are fundamentally not that different and both are descended from 8080.
1 reply →
I started with Z-80 assembly, then BASIC, then 6502 assembly, then higher-level languages like C and perl, and I think the assembly gave me a useful foundation for what was going on under the hood. I'm not sure I'd even call assembly a "language" in the sense of the others. It has instructions, not statements, and there's really no syntax.
If I were teaching a general-interest programming course, I'd probably start with just a bit of BASIC to introduce a few broad concepts like variables and looping, then a little assembly to say, "And this is what's going on when you do those things," and then move up the chain. Then when they get to something like C and go to look at the assembly it produces for debugging, they'll at least be familiar with concepts like registers and branching. So not quite the order I happened to do it in, but similar.
I was a TA for an intro to assembly language course, which means I got my office hours full of all of the students who struggled with assembly language and had to work with them one-on-one to get them over their roadblocks to pass the class.
Assembly language is not a reasonable first programming language. There's just so many things about it that make it a poor choice for programming instruction.
Chiefly, assembly lacks structure. There's no such thing as variables. There's no such thing as functions. You can fake some of this stuff with convention, but if you make mistakes--and students in intro-to-programming will make mistakes--there is nothing that's going to poke you that you did something wrong, you just get the wrong result.
If you have a good macro assembler, it is only a little more difficult than C. There's just more to learn up front (things like calling conventions, register usage, etc...).
I wouldn't teach it first, but after a person knows the basics in another language, seeing how it all actually works can be fun.
I think in most CS programs, students do learn assembly early on, perhaps not as the first language, but definitely as a second language, as required by most Arch courses.
This almost feels like an argument that we should teach computer science via bare metal bootstrapping.
Start out at "here's your machine code. Let's understand how x86_64 gets started" and work your way up to "now you have the automation to compile Linux and a modern compiler".
Which would certainly have stops most of the way up for things we usually include.
So... NAND to Tetris?
Personally way back when, I first learned BASIC, then tried to learn C, but didn't get pointers, then learned ASM, and then pointers became obvious, and went back to C. If you're going to be using C or doing anything with hardware, learning ASM IMO is very useful just to understand how the machine really works.
assembly is a good first language if you have a simple instruction set or machine. When I saw new people learn java, easily the hardest initial bump to get over was "what the hell is public static void main(String[] args) ?" or "eclipse didn't build it for some reason"
Python is much easier to introduce someone to because there's no boilerplate and the tooling is very simple. Assembly on x86 machines is a royal PITA to set up, and you also need some kind of debugger to actively inspect the program counter and registers.
When I took Computer Organization & Architecture, they had us play around with MARIE[1] which really made assembly make sense to me. After that, I wrote an 8080 emulator and it made even MORE sense to me.
---
[1] https://marie.js.org/
> Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level.
Indeed - you don't actually need to work on difficult tasks to get the intellectual benefit. Once you've properly understood what a computer is, you can absorb the ideas of SICP.
Beginners should have immediate positive feedback. It's not possible with assembly language.
It's just as straightforward as in higher level languages, just not quite as interactive as interpreted languages, but I've never seen an "intro to programming" that started in a REPL even when using an interpreted language. Hello world is even shorter and simpler than most languages (in a modern OS environment).
1 reply →
Shenzhen I/O begs to disagree :P
https://www.zachtronics.com/shenzhen-io/
You start with a simulator like this one:
https://edsim51.com/about-the-simulator/
Very immediate and positive feedback.
You can with a decent monitor that shows the values of registers, can look up values in memory, etc.
x86 ASM absolutely is NOT a good first language due to it being a complete mess.
16 bit x86 isn't that complicated and (IMO) still helpful in learning some of the more modern stuff. But I'd recommend starting with either 6502, or the 8080, which is like the 8 bit "grandparent" of x86.
Avoid:
- Z80: at least as a first language. Extended 8080 with completely different syntax, even more messy and unorthogonal than x86!
- RISC-V: an architecture designed by C programmers, pretty much exclusively as a target for compiling C to & omitting anything not necessary for that goal
Here's a similar (and much more indepth) opcode decoding recipe for Z80, very useful for emulator development:
http://www.z80.info/decoding.htm
For actually programming in machine code this understanding of the internal opcode structure isn't all that useful though, usually - without an assembler at hand - you had a lookup table with all possible assembly instructions on the left side, and the corresponding machine code bytes on the right side.
Programming by typing machine code into a hex editor is possible, but really only recommended as absolute fallback if there's no assembler at hand - mainly because you had to keep track of all global constant and subroutine entry addresses - e.g. the main thing that an assembler does for you, and you had to leave gaps at strategic locations so that it is possible to patch the code without having to move things around.
For the past year or so, a couple teen boys from my neighborhood come by on sunday afternoon for a couple hours of programming in python. I started very simply and built up with text based tasks, then showed them pygame.
I am thinking about showing them what is under the hood, that python itself is just a program. When I learned to program it was the late 70s, and trs-80s and apple-IIs were easy to understand at the machine code level.
I could recapitulate that experience for them, via an emulator, but that again just feels like an abstraction. I want them to have the bare-metal experience. But x86 is such a sprawling, complicated instruction set that it is very intimidating. Of course I'd stick to a simplified subset of the instructions, but even then, it seems like a lot more work to make output running on a PC vs on the old 8-bit machines where you write to a specific location and it shows up on the screen.
Buy them a copy of "Human Resource Machine" on Steam or (preferably since there's no DRM) Good Old Games. It's a gamified version of what writing machine language on the old 8 bit CPUs of yore was like. The puzzle challenge in HRM is authentic in the sense that it derives from the natural constraints of having a single accumulator and very simple instructions rather than unnaturally injected constraints like the Zachtronics games, which are good but I wouldn't recommend as a learning tool.
You could try the thing that made it click for me, long after x86 was dominant.
Show them a CPU running on Logisim (or the like, such as the newer Digital) and show how when you plug a program into a ROM, it turns into wires lighting up and flipping gates/activating data lines/read registers etc.
ASM programming is fun. Machine code (as in what ASM encodes to) isn't scary, but it is extremely tedious to work with. I recommend the first part of Casey Muratori's Performance Aware Programming course if you want to feel that pain.
I think you need to do it in production to retain the knowledge. If you just do it as a hobby, then most people just give up at certain point because there is no point to bang your head on the wall for nothing. You need to have a real problem to solve to go a long way.
Thank you Jimmy, great article.
My 23+ year experience in computer science and programming is a zebra of black-or-white moments. For the most time, things are mostly obscure, complicated, dark and daunting. Until suddenly you stumble upon a person who can explain those in simple terms, focus on important bits. You then can put this new knowledge into a well-organized hierarchy in your head and suddenly become wiser and empowered.
"Writing documentation", "talking at conferences", "chatting at a cooler", "writing to a blog" and all the other discussions from twitter to mailing lists - are all about trying to get some ideas and understanding from one head into another, so more people can get elucidated and build further.
And oh my how hard is that. We are lucky to sometimes have enlightenment through great RTFMs.
I started building a Forth recently, but decided that instead of interpreter or transpiler or whatever, I'd map to bytes in memory and just straight execute them.
This non-optimising JIT has been far, far easier than all the scary articles and comments I've seen led me to believe.
I'm already in the middle of making it work on both Aarch64 and RISC-V, a couple weeks in.
We did a similar approach back in the day, when going through the Tiger language[0], on the Java version.
Our approach was to model the compiler IR into Assembly macros, and follow the classical UNIX compiler build pipeline, thus even though it wasn't the most performant compiler in the world, we could nonetheless enjoy having our toy compiler generate real executables in the end.
[0] - https://www.cs.princeton.edu/~appel/modern
I did this for WebAssembly WAT (an IR that is syntactically similar to lisp) by mapping the AST for my lisp more or less directly to the WAT IR, then emitting the bytecode from there. It was pretty fun.
I mean, it’s not hard as such, the encodings of some instruction sets are just ass, with 32- and 64-bit x86 as the foremost example and Thumb-2 not far behind it. Also, if you’re dynamically patching existing code, you’ll have to contend with both modern OSes (especially “hardening” patches thereto) making your life harder in bespoke incompatible ways (see: most of libffi) and modern CPUs being very buggy around self-modifying code. Other than that, it just takes quite a bit of tedious but straightforward work to get anywhere.
I haven't had any issues with the OS.
I mmap, insert, mark as executable and done. Patchjumping and everything "just works".
I'm not modifying my own process, so there's no hardening issues. Just modifying an anonymous memory map.
Very interesting, care to share the source?
Oh, it's still a while off that. I do plan to make it public at some point, but when I'm actually happy the code isn't completely vomit.
But for a simple taste, the push to stack function currently looks like this. (All the emit stuff just writes bytes into a mmap that gets executed later.)
4 replies →
Machine code isn't scary, but its nature is severely misunderstood.
Skipping over the bundling of instructions into code blocks, the next logical construct are functions. These have references to code and data in memory; if you want to relocate functions around in memory you introduce the concept of relocations to annotate these references and of a linker to fix them to a particular location.
But once the linker has done its job, the function is no longer relocatable, you can't move it around... or that is what someone sane might say.
If you can undo the work of the linker, you can extract relocatable functions from executables. These functions can then be reused into new executables, without decompiling them first; after all, if what you've extracted is equivalent to the original relocatable function, you can do the same things than it.
Repeat this process over the entire executable and you're stripped it for parts, ready to be put back together with the linker. Change some parts and you have the ability to modify it as if you're replacing object files, instead of binary patching it in place with all the constraints that comes with it.
Machine code is like Lego bricks, it just takes a rather unconventional point of view (and quite a bit of time to perfect the art of delinking) to realize it.
I taught myself to program on an 8-bit BBC micro-computer in the mid-80s by typing in BASIC listings. I understood BASIC quite well, and could write my own structured BASIC programs, but machine code was always a bit out-of-reach. I would try to read books that started by demonstrating how to add, subtract etc, but I couldn’t see how that could build up to more complicated stuff that I could do in BASIC, like polling for input, or playing sounds, or drawing characters on the screen. Only once I got an advanced users guide and discovered the operating system commands, then it started to click with me - the complicated stuff was just arranging all the right data in the right bits of memory or registers, then (essentially) calling a particular OS command and saying ‘here’s the data you want’.
Yeah the issue is that the pedagogy doesn’t make it clear how to bridge the “calculator” with the OS stuff. I had this issue when I was a kid. How does adding eventually make something draw on the screen? Of course, it doesn’t, you need some hardware or OS specific information
It wasn't until I read Petzold's CODE that this stuff, especially the role of the the motherboard bridging processing, memory and I/O and what an OS is for, that it started to click for me.
1 reply →
But if this doesn't satisfy your curiosity, you might realize this is just pushing the magic blackbox/question mark a little further down the chain
How does the OS and the hardware draw on the screen, actually? All they have is also just calculator stuff, super basic primitives. You can't even do loops in hardware, or even real branches (hardware always "executes both sides" of a branch at once)
Anyways, if you keep digging long enough you eventually end up finding this XKCD https://xkcd.com/435/ =)
10 replies →
It's really interesting to see what people focus on when learning new things. Instruction encoding is something I would consider arcane knowledge, except that it isn't really useful; if you need to write an assembler or a disassembler, you can always look it up, but otherwise assembler instructions is basically all you need. Focusing on the nuances of a specific architecture's encoding is like people studying arithmetic instead of algebra and saying they now understand "math"; like, yes, a little, but there's so much you don't even know you don't know.
I'm absolutely not criticizing the author here, machine code can absolutely be beautiful and I love the "it isn't scary" sentiment, it just surprised me how unique the focus is. In fact, I think this is the first time I've ever read a post on "low-level computer stuff isn't that hard" and it was about machine code rather than assembly.
Then again, I can absolutely see the appeal. Architectures are fun, and I remember myself designing ones all the time in childhood during summer vacation. (Yes, I know I'm autistic.) Seeing tradeoffs between variable-length and fixed-length, short and long instructions, how register count affects code simplicity and the available opcode space, etc. kind of gives you an intuitive understanding of why real-world architectures look the way they do.
In 1982, I programmed my ZX81 by converting assembly to hex by hand because BASIC was just too slow. I'd write my assembly on paper, convert it to hex using reference tables, then use a simple BASIC FOR loop to POKE the values into memory we'd reserved space for the machine code in a REM statement at a fixed position in memory.
When all the values were POKEd in, I'd save to tape and execute it with RAND USR 16514.
That memory address is permanently etched in my brain even now.
It wasn't good, bad or scary it was just what I had to do to make the programs I wanted to make.
I did the same thing, on the 48k Spectrum, a year or two later. I also remembered to add some NOPs between functions, to avoid me having to recalculate all the relative jump instructions if I made changes.
For me the 'scary' part of machine code was never the actual logic. It was always just staring at that wall of hex or mnemonics and feeling like I needed a secret decoder ring!
Yes, that does not help.
To me, it looks like some kind of complex tetris game. I guess we could maybe represent a program as such, with pieces for registers, instructions, etc.
Yet, the tooling we have is very terse, and textual.
Machine code was only "scary" in the old days when you had to reboot your system when you made a small mistake.
I enjoyed having to reload everything from tape (compact cassette tape - ie the kind of thing you'd use with a home computer in the early eighties), after a crash due to my poor code. I think the term used then was "character building" ;)
One of my first C programs wrote straight into the BIOS memory (1989 iirc). The machine froze and refused to reboot. We had to remove the BIOS battery to reset the BIOS. Luckily, the battery wasn't soldered to the main board.
I can relate to you, OP.Sorry for off topic I want to share my experience about my journey of programming. When I started programming, I was introduced to the ideas of variables, conditions, loops, functions—regular programming constructs. But I didn't understand much of what was going on, how the computer worked, or anything beyond just the syntax. I used to wonder: when I start my PC, how does it even know where to begin? I often felt insecure and anxious about all these unknowns. I was trapped in tutorial hell, thinking that just gluing pieces of code together was enough. It made sense for a while, but eventually, I wanted to quit.
After some time, I searched online about how to improve, and people recommended learning data structures and algorithms (DSA). I didn’t know how to implement data structures on my own and struggled a lot—almost like going through hell. Nothing made sense. I couldn’t even get beyond linked lists.
Then I found a Reddit post saying I might have the wrong mental model. It said that even if you know some programming, without understanding how to think about structures and systems, you're stuck. I started searching for what 'mental models' meant, but due to my lack of experience, I didn’t find anything useful.
Later, I read a discussion on Hacker News about the book Structure and Interpretation of Computer Programs (SICP). One commenter explained how the book starts with the concept of data and procedures. That really clicked for me. I had never thought of computation as just transforming input data into output data. The model of:
Input → Computation → Output
made everything fall into place. This idea carries through all levels of programming—whether it's assembly, mid-level, or high-level languages. It’s the fundamental notion. You need basic constructs to steer data through transformations into useful outputs. Computation is essentially about transforming one form of information into another.
After that realization, everything started to make sense—assembly, high-level programming, even operating systems. It was one of the best ‘aha!’ moments of my life."
Data, data, data :))) Some basic notions to know:
Input → Computation → Output
Information is omnipresent (this is just an intuition, not a claim). It serves as both input and output.
Computation—also known as a procedure, function, set of instructions, transformation, method, algorithm, or calculation.
In my early days, I ignored the fundamental notion of data and procedures. But eventually, it clicked: Programs = Data + Instructions
Watch Feynman on computing—he even starts with the same concept of data, introducing computers as information processing systems. And processing requires algorithms (i.e., instructions or procedures).
Programming is simply writing instructions for the computer to perform computations.
A computer is just a machine for computing.
Computation is a general idea: a transformation of one form of information into another.
Machine code ceased to be scary, or at least mysterious, to me when I opened the rudimentary debugger on a TRS-80. It was really more of a monitor, and it showed the contents of a certain chunk of memory in the top half of the screen. I loaded a program I was working on into it, and began changing instructions in memory, using the assembler output as my guide, and jumping into the program to see what the effects were. After that the little lightbulb went off. Oh, these are just bytes in memory that correspond to CPU instructions, and the CPU just reads them off and executes the instructions.
That is one thing that was nice about DOS, you where close to the machine. I never fully got machine language, but it was fun trying.
IIRC, debug.com could be used to create programs using machine lang.
Yes, it was a quite bare bones experience when compared to TASM and MASM, and only worked for COM executable, but it did work.
The reasoning being that COM files were a plain memory dump starting at offset 100H, thus you would type the code in memory and then dump it.
This is the video I wished I had seen when I was a kid, feeling like assembly was a dark art that I was too dumb to be able to do. Later in life I did a ton of assembly professionally on embedded systems. But as a kid I thought I wasn’t smart enough. This idea is poison, thinking you’re not smart enough, and it ruins lives.
https://youtu.be/ep7gcyrbutA?si=8HiMqH2mMwsJRNDg
[dead]
I always thought machine code was something only experts could understand. But after reading this article, I realized the basic concepts aren’t that complicated, it’s really just instructions, registers, and memory. I feel like this has given me a clearer understanding when it comes to writing code.
Wrong article ;)
(I think you mean https://news.ycombinator.com/item?id=44184900)
Thank you very much for your reminder. The comment has been corrected.
When I was last working with machine code, I found capstone to be very useful. Even just reading the source was helpful for some of the conditionally present amd64 fields.
https://github.com/capstone-engine/capstone
It is downright scary, these assemblers.
Tracking all those transitions of multiple micro-register states between each pair of opcode instructions, oy!
Disclaimer: designed 6502 instruction set. Flabbergasted at today's Intel instruction set!
Thank the gods for compilers!
Oh, cool. A couple years ago I spent a few days disassembling a small x86-64 binary by hand. Getting familiar with the encoding was a lot of fun! The following reference was indispensable:
http://ref.x86asm.net/
Ok, what about VLIW ASM? Have you ever seen Elbrus' ASM with predicated code, asynchronous Array Prefetch Buffer, rotating registers, DAM (hardware table to memory dependencies disambiguation), registers windows etc. It's really hard to start read this.
Is it enough to play Human Resource Machine!? https://en.wikipedia.org/wiki/Human_Resource_Machine
Assembly as a game, I loved playing it.
> Is it enough to play Human Resource Machine!?
That is fun. But this one truly is enough: Turing Complete. You start with boolean logic gates and progressively work your way up to building your own processor, create your own assembly language, and use it to do things like solve mazes and more. Super duper fun
https://store.steampowered.com/app/1444480/Turing_Complete/
> But what if we want to represent a number larger than 12 bits? Well, the add instruction doesn't let us represent all such numbers; but setting sh to 1 lets us shift our number by 12 bits. So for example we can represent 172032172032 by leaving our 42 alone and setting sh to 1. This is a clever technique for encoding larger numbers in a small space.
This is whacky. So presumably adding with a 24-bit constant whose value isn't representable in this compressed 13-bit format would then expand to two add instructions? Or would it store a constant to a register and then use that? Or is there a different single instruction that would get used?
(Also, typo, 42 << 12 is 172032).
Yes, it would:
The same happens e.g. on RISC-V:
Because there are only 32 bits in an instruction, you can't fit a whole 32-bit immediate into it. Contrast it with x86 which uses variable-length instructions (up to 15 bytes per instruction):
P.S. Some people seem to be really puzzled by LEA instructions. It's intended use is to correspond to C's "dest = &base[offset]" which semantically is just "dest = base + offset", of course — but it allows one to express base and/or offset using available addressing modes.
The thing is: most programmers see assembly language generated by a compiler, so no comment, and in optimised code with vector operations, it IS scary.
Well, machine code is scary. But like with many scary things, once you overcome your fears and get familiar with the thing, you realize that it is not that bad.
This is a tangent but yesterday I was just pondering the abstraction layer from machine code to assembly lexers to compilers to interpreted languages. Having been lucky enough to be born at a time to witness these shifts, it's so easy to forget what we used to think was normal.
The thought came to me when testing the new Jules agentic coding platform. It occured to me that we are just in another abstraction cycle, but like those before, it's so hard to see the shift when everything is shifting.
My conclusion? There will be non-AI coders, but they will be as rare as C programmers before we realize it.
I think machine code and building something like a Forth is way easier to understand than any contemporary programming language toolchain.
Indeed. In Knuth’s Art the machine code was not the “scariest” part. (Programming is hard.)
I think this article is missing a major point, or perhaps should be titled "Some Non-Scary Machine Code Isn't Scary". It argues that machine code isn't scary, by building a one-to-one mapping from machine code to assembly code, and then taking it as given that assembly code isn't scary. But it uses two examples -- 32-bit ARM and x86-64 -- where this one-to-one mapping isn't valid. When in Thumb mode for (some flavors of) ARM, even when you know you're in thumb mode, instructions can be a mix of 16 and 32 bits. And in x86 world, of course, instructions can be a wide range of widths. What that means is that if you're given a chunk of memory that is known to contain executable instructions... you /can't/ build a one-to-one mapping to assembly without knowing where all of the entry points are. For well-formed code you can often exclude almost all possible entry points as invalid, and maybe even end up with only a single one... but it's perfectly possible (and quite fun) to write machine code that has valid, different behavior for different entry points to the same byte sequence. There's no way to reduce this type of machine code to meaningful assembly, and it should be considered scary.
[dead]