[banachtarski]

There absolutely is still black magic between you and the hardware and thinking otherwise can lead to trouble. Yes you can read the architecture documentation but when you get into the realm of how the branch prediction tables work, register allocation schemes, operation reordering etc, what the hardware does will be "special" while (usually) not violating what the architecture specifies. Don't even get me started with load/store semantics for multithreaded architectures (although this is standardizing more with the more recent ARM)

[anjbe]

Sure, but the Game Boy’s pseudo‐Z80 has no branch prediction, register allocation, or instruction reordering. The assembly is almost one‐to‐one to the machine code, and the CPU basically does everything in the straightforward way you’d expect.

[kbp]

Even on the Gameboy things aren't quite as simple and self evident as all that, for example from another thread on this post: when the Game Boy's screen is rendering (i.e. almost all the time), the CPU doesn't have access to VRAM. [...] writes are ignored, and reads return garbage.

So one of those platonic store instructions might actually be a no-op; you can't tell by looking at it in isolation.

[banachtarski]

I was replying directly to a response which generalizes the subject of the original post.

[ctw]

I was hoping someone would say something along these lines. My only experience with assembly has been on very simple educational platforms: nios ii on an Altera DE0 FPGA and a MIPS subset on a custom architecture made in class. I've seen photos of the huge x86 reference manual and can see how "real-life" systems would be way more complex than the simple world of assembly I've tried myself.