+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

   foo() ? bar() : baz(); 

    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.

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

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

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

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

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

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.

This post was very helpful when I tried to figure it out: https://dougallj.wordpress.com/2021/10/30/bit-twiddling-opti...

I expect a sufficiently good macro assembler should be able to do it as well.

> 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

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!

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

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.

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

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.

So... NAND to Tetris?

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

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.

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.

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.

Thank you very much for your reminder. The comment has been corrected.