One thing I don’t like about these articles in general is they omit a very important step in describing assembly: how it’s actually used by a computer. I’ll give a brief intro to folks and hopefully not confuse things any further. If you want hands on experience, grab an STM32 Nucleo board, or do Ben Eater’s 8-bit processor DIY course. This is now getting into a very closely related subject matter called Embedded Systems via foundational electronics and electrical engineering studies. Anyone interested in this - may the Gods be on your side.

So, here we go. Blog post as a comment.

Assembly and mnemonics are there to be human readable representations of a fictitious thing called bits which are always “stored somewhere”. Now, bits don’t actually exist, nor does their storage, but voltage differences, magnetic/electric fields and currents do. There are no intermediate layers in hardware that translate your “program” into this pattern - your “files” already exist in as this pattern somewhere because again, it’s voltages, fields, and currents, and that’s all there is. This means all those abstractions and OSI layers don’t exist - all that stuff is make-believe. Files and file systems don’t exist. Hence, assembly doesn’t exist.

I’ll skip over a thing called microcode and microarchitecture. Both of these deal with taking your bit pattern and re-arranging it into a different pattern that the exact processor you’re using is optimized/carefully designed for and doing other mean things to your program. In general you wont encounter this when doing assembly or any other high level language, but certain processors do allow for some play at program-level. You can configure the processor exactly how you want it to function and this is packaged with your program code.

Now, when we talk about data buses, instruction buses, “cache lines”, and all these things what we are really talking about are parallel traces on a circuit board on which one can sample, usually though not always, a voltage difference on each trace and see if it’s “high” or “low” (your “bit”). The number of these traces usually corresponds to the number of bits. Hence, an 8-bit, 16-bit, 9-bit and a 32-bit processor again, usually though not always will have physical lines on a circuit board corresponding to this number. Hence, your assembly instruction is an English term for an ordering of these lines at a point in time.

Here’s the OG 8086 processor chip. You can see physically it has AD0 to AD15 pins, hence 16 “bits” of voltage levels that are “high” or “low”: https://www.geeksforgeeks.org/pin-diagram-8086-microprocesso...

So your assembly instruction is an arrangement of the voltage levels for these pins. The processor samples it, and proceeds to raise or lower other pins it has. And it goes round and round like this until it overheats and dies on you after some years of abuse.

You write your program, you store this in “memory” as an ordered arrangement of voltages/fields. A “controller” reads this and presents the processor at any point in time with the voltage levels, directly hooked up to its pins. The processor goes ahead and does it’s thing. There’s very little rocket surgery to it.

Processors of course are not usually this simple. They are nowadays structured do many steps at once, often times abusing a clock (again, voltage differences) and decreasing sizes of chips to go faster and faster.

One point to mention here is, you can probably now see that the data pins of something like an 8086 can literally be hooked up to anything - there’s no separation between “code” and “data”. By now you should understand that these, too, are make-believe. A pattern of signals is a pattern of signals no matter where it’s coming from. Although some processors will tell you otherwise and they get fancy with a thing called memory maps. They too, don’t exist.

So, armed with this hopefully demystifies for you a bit the why of assembly. It’s a convenient, human readable form of instructions that a processor can execute. It is a fairly banal and trivial thing in the end. The real guts of it is knowing how the processor will execute it, what it will do before and after. Assembly as a language can be picked up relatively quickly.

It should be noted that, should you choose to, you can open up the manual of your favourite processor, and chances are highly likely you’ll get a listing of not only mnemonics (for your reading pleasure), but the aforementioned voltage levels and functions of each of the of pins, as well as the “bit pattern” for each instruction. Some manuals will, if you’re really lucky, tell you how to design your circuit board for the processor to function properly, how far your memory is allowed to physically be from the processor, and what other things you must keep in mind.

Clear as mud?

(epilogue: if you’ve found this info tickles your fancy, you should definitely look into electronics and start building circuits, both analog and digital ones, get comfortable with reading data sheets and understanding how processors interact with the peripherals around them to perform their duties. This is an immense field of lots of things which would fascinate you and are truly science fiction.)

A Friendly Introduction to Assembly for High-Level Programmers