Machine Code Isn't Scary

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

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.

But of course, might not be that rosy if under great time constraints.

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

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

I deeply hate this attitude in modern compiler design.

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.

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.

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.

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

I am curious what specific examples do you have of the HW and OS being made/written to make ASM convenient?

But for tinkering (e.g writing GBA/NES games), hell why not? It's fun.

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

A friend of mine who also had a CoCo wrote an assembler as a term project.

    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.

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

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.

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.

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.

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.

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!

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

Not doing this is how you get Electron.

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.

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.

- 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

https://www.zachtronics.com/shenzhen-io/

https://edsim51.com/about-the-simulator/

Very immediate and positive feedback.

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

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.

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.

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

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