Machine Code Isn't Scary

> 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 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 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.

> 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 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 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.

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.

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.

> (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?

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.

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.

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.

"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!

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.

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).

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.

   https://fingswotidun.com/dcpu16/pac.html

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.

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.)

    void compile_push_literal(Value val) {
    #if ARCH_X86_64
        emit_bytes((uint8_t[]){X86_MOV_RDI_IMM64_0, X86_MOV_RDI_IMM64_1}, 2); emit_uint64_le(val);
        emit_bytes((uint8_t[]){X86_MOV_RAX_IMM64_0, X86_MOV_RAX_IMM64_1}, 2); emit_uint64_le((uint64_t)push);
        emit_bytes((uint8_t[]){X86_CALL_RAX_0, X86_CALL_RAX_1}, 2);
    #elif ARCH_ARM64
        uint64_t imm = val;
        emit_uint32_le(ARM64_MOVZ_OP | (ARM64_REG_X0 << 0) | ((imm & 0xFFFF) << 5));
        emit_uint32_le(ARM64_MOVK_OP_LSL16 | (ARM64_REG_X0 << 0) | (((imm >> 16) & 0xFFFF) << 5));
        emit_uint32_le(ARM64_MOVK_OP_LSL32 | (ARM64_REG_X0 << 0) | (((imm >> 32) & 0xFFFF) << 5));
        emit_uint32_le(ARM64_MOVK_OP_LSL48 | (ARM64_REG_X0 << 0) | (((imm >> 48) & 0xFFFF) << 5));
        uint64_t func_addr = (uint64_t)push;
        emit_uint32_le(ARM64_MOVZ_OP | (ARM64_REG_X1 << 0) | ((func_addr & 0xFFFF) << 5));
        emit_uint32_le(ARM64_MOVK_OP_LSL16 | (ARM64_REG_X1 << 0) | (((func_addr >> 16) & 0xFFFF) << 5));
        emit_uint32_le(ARM64_MOVK_OP_LSL32 | (ARM64_REG_X1 << 0) | (((func_addr >> 32) & 0xFFFF) << 5));
        emit_uint32_le(ARM64_MOVK_OP_LSL48 | (ARM64_REG_X1 << 0) | (((func_addr >> 48) & 0xFFFF) << 5));
        emit_uint32_le(ARM64_BLR_OP | (ARM64_REG_X1 << 5));
    #elif ARCH_RISCV64
        emit_load_imm_riscv(val, RISCV_REG_A0, RISCV_REG_T1);
        emit_load_imm_riscv((uint64_t)push, RISCV_REG_T0, RISCV_REG_T1);
        emit_uint32_le((0 << 20) | (RISCV_REG_T0 << 15) | (RISCV_F3_JALR << 12) | (RISCV_REG_RA << 7) | RISCV_OP_JALR);
    #endif
    }

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.

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/ =)

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.