Addressing the adding situation

> Using `lea` […] is useful if both of the operands are still needed later on in other calculations (as it leaves them unchanged)

As well as making it possible to preserve the values of both operands, it’s also occasionally useful to use `lea` instead of `add` because it preserves the CPU flags.

>However, in this case it doesn’t matter; those top bits5 are discarded when the result is written to the 32-bit eax.

>Those top bits should be zero, as the ABI requires it: the compiler relies on this here. Try editing the example above to pass and return longs to compare.

Sorry, I don't understand. How could the compiler both discard the top bits, and also rely on the top bits being zero? If it's discarding the top bits, it won't matter whether the top bits are zero or not, so it's not relying on that.

This guy is tricking us into learning assembly! Get 'em!!

As a side note of appreciation, I think that we can't do better than what he did for being transparent that LLM was used but still just for the proof-reading.

Loving this series! I'm currently implementing a z80 emulator (gameboy) and it's my first real introduction to CISC, and is really pushing my assembly / machine code skills - so having these blog posts coming from the "other direction" are really interesting and give me some good context.

I've implemented toy languages and bytecode compilers/vms before but seeing it from a professional perspective is just fascinating.

That being said it was totally unexpected to find out we can use "addresses" for addition on x86.

Do we really know that LEA is using the hardware memory address computation units? What if the CPU frontend just redirects it to the standard integer add units/execution ports? What if the hardware memory address units use those too?

It would be weird to have 2 sets of different adders.

The confusing thing about LEA is that the source operands are within a '[]' block which makes it look like a memory access.

I'd love to know why that is.

I think the calculation is also done during instruction decode rather than on the ALU, but I could be wrong about that.

Honestly, x86 is not nearly as CISC as those go. It just has a somewhat developed addressing modes comparing to the utterly anemic "register plus constant offset" one, and you are allowed to fold some load-arithmetic-store combinations into a single instruction. But that's it, no double- or triple-indexing or anything like what VAXen had.

    BINOP   disp(rd1+rd2 shl #N), rs

        vs.

    SHL     rTMP1, rd2, #N
    ADD     rTMP1, rTMP1, rd1
    LOAD    rTMP2, disp(rTMP1)
    BINOP   rTMP2, rTMP2, rs
    STORE   disp(rTMP1), rTMP2