7 ms·

Addressing the adding situation

272 points by messe 10mo ago

miningape 10mo ago
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.
- Joker_vD 10mo ago
  A seasoned C programmer knows that "&arr[index]" is really just "arr + index" :) So in a sense, the optimizer rewrote "x + y" into "(int)&(((char*)x)[y])", which looks scarier in C, I admit.
  - crote 10mo ago
    The horrifying side effect of this is that "arr[idx]" is equal to "idx[arr]", so "5[arr]" is just as valid as "arr[5]". Your colleagues would probably prefer if you forget this.
    - rocqua 10mo ago
      That depends on sizeof(*arr) no?
      - unwind 10mo ago
        Not in C no, since arithmetic on a pointer is implicitly scaled by the size of the value being pointed at (this statement is kind of breaking the abstraction ... oh well).
      - messe 10mo ago
        Nope, a[b] is equivalent to *(a + b) regardless of a and b.
        sureglymop 10mo ago
        Given that, why don't we use just `*(a + b)` everywhere? Wouldn't that be more verbose and less confusing? (genuinely asking)
        tomsmeding 10mo ago
        Do you really think that `*(a + i)` is clearer than `a[i]`?
        sureglymop 10mo ago
        Not necessarily. I think it's confusing when there are two fairly close ways to express the same thing.
    - Joker_vD 10mo ago
      > so "5[arr]" is just as valid as "arr[5]" This is, I am sure, one of the stupid legacy reasons we still write "lr a0, 4(a1)" instead of more sensible "lr a0, a1[4]". The other one is that FORTRAN used round parentheses for both array access and function calls, so it stuck somehow.
      - beng-nl 10mo ago
        Yes, I find this one of the weird things about assembly - appending (or pretending?) a number means addition?! - even after many many years of occasionally reading/writing assembly, I’m never completely sure what these instructions do so I infer from context.
      - kragen 10mo ago
        Generally such constant offsets are record fields in intent, not array indices. (If they were array indices, they'd need to be variable offsets obtained from a register, not immediate constants.) It's reasonable to think of record fields as functions: .equ car, 0 .equ cdr, 8 .globl length length: test %rdi, %rdi # nil? jz 1f # return 0 mov cdr(%rdi), %rdi # recurse on tail of list call length inc %rax ret 1: xor %eax, %eax ret To avoid writing out all the field offsets by hand, ARM's old assembler and I think MASM come with a record-layout-definition thing built in, but gas's macro system is powerful enough to implement it without having it built into the assembler itself. It takes about 13 lines of code: http://canonical.org/~kragen/sw/dev3/mapfield.S http://canonical.org/~kragen/sw/dev3/mapfield.S Alternatively, on non-RISC architectures, where the immediate constant isn't constrained to a few bits, it can be the address of an array, and the (possibly scaled) register is an index into it. So you might have startindex(,%rdi,4) for the %rdi'th start index: .data startindex: .long 1024 .text .globl length length: mov (startindex+4)(,%rdi,4), %eax sub startindex(,%rdi,4), %eax ret If the PDP-11 assembler syntax had been defined to be similar to C or Pascal rather than Fortran or BASIC we would, as you say, have used startindex[%rdi,4]. This is not very popular nowadays both because it isn't RISC-compatible and because it isn't reentrant. AMD64 in particular is a kind of peculiar compromise—the immediate "offset" for startindex and endindex is 32 bits, even though the address space is 64 bits, so you could conceivably make this code fail to link by placing your data segment in the wrong place. (Despite stupid factionalist stuff, I think I come down on the side of preferring the Intel syntax over the AT&T syntax.)
    - miningape 10mo ago
      Mom, please come pick me up. These kids are scaring me.
Joker_vD 10mo ago
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 And all it really takes to support this is just adding a second (smaller) ALU on your chip to do addressing calculations.
- andrepd 10mo ago
  Would this matter for performance? You already have so many execution units that are actually difficult to keep fully fed even when decoding instructions and data at the speed of cache.
  - gpderetta 10mo ago
    Yes. As Joker_vD hints on a sibling comment, this is what killed all the classic CISCs during the OoO transition except for x86 that lacks the more complex addressing modes (and the PPro was still considered a marvel of engineering that was assumed not to be possible).
- rocqua 10mo ago
  There's also a lot of specialized instructions like AES ones. But the main thing that makes x86 CISC to me is not the actual instruction set, but the byte encoding, and the complexity there.
  - Joker_vD 10mo ago
    Eh, that's really just a side effect of almost 50 years of constant evolution from a 8-bit microprocessor. Take look at VAX [0], for instance: its instruction encoding is pretty clean yet it's an actual example of a CISC ISA that was impossible to speed up like, literally: DEC engineers tried very hard and concluded that making a truly pipelined & super-scalar implementation was basically impossible; so DEC had to move to Alpha. See [1] for more from John Mashey. Edit: the very, very compressed TL;DR is that if you do only one memory load (or one memory load + store back into this exact location) per instruction, it scales fine. But the moment you start doing chained loads, with pre- and post-increments which are supposed to write back changed values into the memory and be visible, and you have several memory sources, and your memory model is actually "strong consistency", well, you're in a world of pain. [0] https://minnie.tuhs.org/CompArch/Resources/webext3.pdf https://minnie.tuhs.org/CompArch/Resources/webext3.pdf [1] https://yarchive.net/comp/vax.html https://yarchive.net/comp/vax.html
pansa2 10mo ago
> 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.
- andrepd 10mo ago
  Funny to see a comment on HN raising this exact point, when just ~2 hours ago I was writing inline asm that used `lea` precisely to preserve the carry flag before a jump table! :)
  - MYEUHD 10mo ago
    I'm curious, what are you working on that requires writing inline assembly?
    - veltas 10mo ago
      I'm not them but whenever I've used it it's been for arch specific features like adding a debug breakpoint, synchronization, using system registers, etc. Never for performance. If I wanted to hand optimise code I'd be more likely to use SIMD intrinsics, play with C until the compiler does the right thing, or write the entire function in a separate asm file for better highlighting and easier handing of state at ABI boundary rather than mid-function like the carry flags mentioned above.
      - vlovich123 10mo ago
        Generally inline assembly is much easier these days as a) the compiler can see into it and make optimizations b) you don’t have to worry about calling conventions
        Someone 10mo ago
        > the compiler can see into it and make optimizations Those writing assembler typically/often think/know they can do better than the compiler. That means that isn’t necessarily a good thing. (Similarly, veltas comment above about “play with C until the compiler does the right thing” is brittle. You don’t even need to change compiler flags to make it suddenly not do the right thing anymore (on the other hand, when compiling for a different version of the CPU architecture, the compiler can fix things, too)
sethops1 10mo ago
This guy is tricking us into learning assembly! Get 'em!!
- mattgodbolt 10mo ago
  My nefarious plan has been exposed!!
  - EdwardDiego 10mo ago
    I hope you have a moustache you can twiddle while saying this. Possibly followed by a "Nyah!"
- Sophira 10mo ago
  People were probably already tricked into learning assembly when they played Human Resource Machine. A lot of people think it's a "teaching programming" game, and it sorta is, but it's actually teaching assembly language skills!
Thorrez 10mo ago
>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.
- Joker_vD 10mo ago
  (Almost) any instruction on x64 that writes to a 32-bit register as destination, writes the lower 32-bits of the value into the lower 32 bits of the full 64-bit register and zeroes out the upper 32 bits of the full register. He touched on it in his previous note "why xor eax, eax". But the funny thing is, the x64-specific supplement for SysV ABI doesn't actually specify whether the top bits should be zeroes or not (and so, if the compiler could rely on e.g. function returning ints to have upper 32 bits zeroes, or those could be garbage), and historically GCC and Clang diverged in their behaviour.
- 201984 10mo ago
  He's actually wrong on the ABI requiring the top bits to be 0. It only requires that the bottom 32 bits match the parameter, but the top bits of a 32-bit parameter passed in a 64-bit register can be anything (at least on Linux). You can see that in this godbolt example: https://godbolt.org/z/M1ze74Gh6 https://godbolt.org/z/M1ze74Gh6 The reason the code in his post works is because the upper 32 bits of the parameters going into an addition can't affect the low 32 bits of the result, and he's only storing the low 32 bits.
  - fweimer 10mo ago
    The LLVM x86-64 ABI requires the top bits to be zero. GCC treats them as undefined. Until a recent clarification, the x86-64 psABI made the upper bits undefined by omission only, which is why I think most people followed the GCC interpretation. https://github.com/llvm/llvm-project/issues/12579 https://github.com/llvm/llvm-project/issues/12579 https://groups.google.com/g/x86-64-abi/c/h7FFh30oS3s/m/Gksanh3WAAAJ https://groups.google.com/g/x86-64-abi/c/h7FFh30oS3s/m/Gksan... https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/61 https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/61
greatgib 10mo ago
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.
- jfindper 10mo ago
  It does make me curious about the what the super anti-ai people will do. Matt Godbolt is, obviously, extremely smart and has a lot of interesting insight as a domain expert. But... this was LLM-assisted. So, anyone who has previously said they'll never (knowingly) read anything that an ai has touched (or similar sentiment) are you going to skip this series? Make an exception?
  - joaohaas 10mo ago
    I think most people wouldn't call proof-reading 'assistance'. As in, if I ask a colleague to review my PR, I wouldn't say he assisted me. I've been throwing my PR diffs at Claude over the last few weeks. It spits a lot of useless or straight up wrong stuff, but sometimes among the insanity it manages to get one or another typo that a human missed, and between letting a bug pass or spending extra 10m per PR going through the nothingburguers Claude throws at me, I'd rather lose the 10m.
  - themafia 10mo ago
    > what the super anti-ai people will do. Just not use it. I couldn't care less if other people spend hours prompt engineering to get something that approaches useful output. If they want their reputation staked on it's output that's on them. The results are already in and they're not pretty. I just personally think it's absurd to spend trillions of dollars and watts to create an advanced spell checker. Even more so to see this as a "revolution" of any sort or to not expect a new AI-winter once this bubble pops.
    - jfindper 10mo ago
      The question was about reading stuff ai touched, not using ai stuff. But I'm glad you could get that off your chest!
secondcoming 10mo ago
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.
- trollbridge 10mo ago
  LEA is the equivalent of & in C. It gives you the address of something. Fun question: what does the last line of this do? MOV BP,12 LEA AX,[BP] MOV BX,34 LEA AX,BX
  - hota_mazi 10mo ago
    I think OP was just making a comment on the asymmetry of the syntax. Brackets [] are usually used to dereference. Why is this written lea eax, [rdi + rsi] instead of just lea eax, rdi + rsi ?
    - secondcoming 10mo ago
      Yes, that’s what I meant
      - HarHarVeryFunny 10mo ago
        LEA stands for Load Effective Address, so the syntax is as-if you're doing a memory access, but you are just getting the calculated address, not reading or writing to that address. LEA would normally be used for things like calculating address of an array element, or doing pointer math.
    - Y_Y 10mo ago
      The way I rationalize it is that you're getting the address of something. A raw address isn't what you want the address of, so you're doing something like &(*(rdi+rsi)).
    - jcranmer 10mo ago
dist-epoch 10mo ago
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.
- adrian_b 10mo ago
  The modern Intel/AMD CPUs have distinct ALUs (arithmetic-logic units, where additions and other integer operations are done; usually between 4 ALUs and 8 ALUs in recent CPUs) and AGUs (address generation units, where the complex addressing modes used in load/store/LEA are computed; usually 3 to 5 AGUs in recent CPUs). Modern CPUs can execute up to between 6 and 10 instructions within a clock cycle, and up to between 3 and 5 of those may be load and store instructions. So they have a set of execution units that allow the concurrent execution of a typical mix of instructions. Because a large fraction of the instructions generate load or store micro-operations, there are dedicated units for address computation, to not interfere with other concurrent operations.
  - dist-epoch 10mo ago
    But can the frontend direct these computations based on what's available? If it sees 10 LEA instructions in a row, and it has 5 AGU units, can it dispatch 5 of those LEA instructions to other ALUs? Or is it guaranteed that a LEA instruction will always execute on an AGU, and an ADD instruction always on an ALU?
    - adrian_b 10mo ago
      This can vary from CPU model to CPU model. No recent Intel/AMD CPU executes directly LEA or other instructions, they are decoded into 1 or more micro-operations. The LEA instructions are typically decoded into either 1 or 2 micro-operations. The addressing modes that add 3 components are usually decoded into 2 micro-operations, like also the obsolete 16-bit addressing modes. The AGUs probably have some special forwarding paths for the results towards the load/store units, which do not exist in ALUs. So it is likely that 1 of the up to 2 LEA micro-operations are executed only in AGUs. On the other hand, when there are 2 micro-operations it is likely that 1 of them can be executed in any ALU. It is also possible for the micro-operations generated by a LEA to be different from those of actual load/store instructions, so that they may also be executed in ALUs. This is decided by the CPU designer and it would not be surprising if LEAs are processed differently in various CPU models.
tony-john12 10mo ago
[dead]
f311a 10mo ago
What's the current best resources to learn assembly? So that I can understand output of simple functions. I don't want to learn to write it properly, I just want to be able to understand on what's happening.
- photochemsyn 10mo ago
  https://godbolt.org/ https://godbolt.org/ You can select the assembly output (I like RISCV but you can pick ARM, x86, mips, etc with your choice of compiler) and write your own simple functions. Then put the original function and the assembly output into an LLM prompt window and ask for a line-by-line explanation. Also very useful to get a copy of Computer Organization and Design RISC-V Edition: The Hardware Software Interface, by Patterson and Hennessy.
stassats 10mo ago
The text mentions that it can also do multiplication but doesn't expand on that. E.g. for x * 5 gcc issues lea eax, [rdi+rdi*4].
- xg15 10mo ago
  It also says the multiplier must be one of 2, 4 or 8. So I guess this trick then only works for multiplication by 2, 3, 4, 5, 8 or 9?
  - stassats 10mo ago
    The tricks to avoid multiplication (and division) are probably worth a whole post. x * 6: lea eax, [rdi+rdi*2] add eax, eax x * 7: lea eax, [0+rdi*8] sub eax, edi x * 11: lea eax, [rdi+rdi*4] lea eax, [rdi+rax*2] But with -Os you get imul eax, edi, 6 And on modern CPUs multiplication might not be actually all that slow (but there may be fewer multiply units).
    - mattgodbolt 10mo ago
      Hey now; let's not get ahead too far :) I'm trying to keep each one bite-sized...I don't think you'll be (too) disappointed at the next few episodes :)
mordechai9000 10mo ago
This triggers a vague memory of trying to figure out why my assembler (masm?) was outputting a LEA instead of a MOV. I can't remember why. Maybe LEA was more efficient, or MOV didn't really support the addressing mode and the assembler just quietly fixed it for you. In any case, I felt slightly betrayed by the assembler for silently outputting something I didn't tell it to.
- HarHarVeryFunny 10mo ago
  LEA and MOV are doing different things. LEA is just calculating the effective address, but MOV calculates the address then retrieves the value stored at that address. e.g. If base + (index * scale) + offset = 42, and the value at address 42 is 3, then: LEA rax, [base + index * scale + offset] will set rax = 42 MOV rax, [base + index * scale + offset] will set rax = 3
  - dataflow 10mo ago
    I assumed they're referring to register-register moves?
    - HarHarVeryFunny 10mo ago
      OK, so: LEA eax, [ebx] instead of: MOV eax, ebx But of course: MOV eax, [ebx] is not the same.
xjm 10mo ago
Part of the Advent of Compiler Optimisations https://xania.org/AoCO2025 https://xania.org/AoCO2025 Loving it so far!
egurns 10mo ago
> Yesterday we saw how compilers zero registers efficiently. It took several tries to understand zero is a verb
- gbacon 10mo ago
  Verbing weirds language.
  - deleted 10mo ago
    [deleted]
  - pwdisswordfishy 10mo ago
    Zero-suffixing does weird language.
  - mattgodbolt 10mo ago
    Tell me about it...someone turned my name into a verb...
- delta_p_delta_x 10mo ago
  It might have been a little bit clearer to say: Yesterday we saw how compilers zero out registers efficiently. Or better still: Yesterday we saw how compilers set the values in registers to zero efficiently.
- kragen 10mo ago
  Often I use "zeroize" rather than "zero" to avoid such confusion.
zahlman 10mo ago
It's still wild to me that "Godbolt" is an actual surname.
- xg15 10mo ago
  Someone had a very talented archer as an ancestor.
badmonster 10mo ago
[flagged]
- kragen 10mo ago
  Human assembly programmers on the 8086 used LEA all the fucking time. And I'm not sure good ISA design is characterized by the need for ingenious hacks to get the best mileage out of the hardware; rather the opposite, in my view. The ARM2's ISA design is head and shoulders better than the 8086's.
sparkie 10mo ago
> x86 is unusual in mostly having a maximum of two operands per instruction[2] Perhaps interesting for those who aren't up to date, the recent APX extension allows 3-operand versions of most of the ALU instructions with a new data destination, so we don't need to use temporary registers - making them more RISC-like. The downside is they're EVEX encoded, which adds a 4-byte prefix to the instruction. It's still cheaper to use `lea` for an addition, but now we will be able to do things like or rax, rdx, rcx https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html https://www.intel.com/content/www/us/en/developer/articles/t...
jxors 10mo ago
> However, in this case it doesn’t matter; those top bits are discarded when the result is written to the 32-bit eax. Fun (but useless) fact: This being x86, of course there are at least three different ways [1] to encode this instruction: the way it was shown, with an address size override prefix (giving `lea eax, [edi+esi]`), or with both a REX prefix and an address size override prefix (giving `lea rax, [edi+esi]`). And if you have a segment with base=0 around you can also add in a segment for fun: `lea rax, cs:[edi+esi]` [1]: not counting redundant prefixes and different ModRMs
Aaron2222 10mo ago
This trick is something we teach our students when we do 6809 assembly (mainly as a trick to do addition on the index registers). I had no idea it was used as an optimisation in x86.

272 points by messe 10mo ago

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.

Joker_vD 10mo ago
A seasoned C programmer knows that "&arr[index]" is really just "arr + index" :) So in a sense, the optimizer rewrote "x + y" into "(int)&(((char*)x)[y])", which looks scarier in C, I admit.
- crote 10mo ago
  The horrifying side effect of this is that "arr[idx]" is equal to "idx[arr]", so "5[arr]" is just as valid as "arr[5]". Your colleagues would probably prefer if you forget this.
  - rocqua 10mo ago
    That depends on sizeof(*arr) no?
    - unwind 10mo ago
      Not in C no, since arithmetic on a pointer is implicitly scaled by the size of the value being pointed at (this statement is kind of breaking the abstraction ... oh well).
    - messe 10mo ago
      Nope, a[b] is equivalent to *(a + b) regardless of a and b.
      - sureglymop 10mo ago
        Given that, why don't we use just `*(a + b)` everywhere? Wouldn't that be more verbose and less confusing? (genuinely asking)
        tomsmeding 10mo ago
        Do you really think that `*(a + i)` is clearer than `a[i]`?
        sureglymop 10mo ago
        Not necessarily. I think it's confusing when there are two fairly close ways to express the same thing.
  - Joker_vD 10mo ago
    > so "5[arr]" is just as valid as "arr[5]" This is, I am sure, one of the stupid legacy reasons we still write "lr a0, 4(a1)" instead of more sensible "lr a0, a1[4]". The other one is that FORTRAN used round parentheses for both array access and function calls, so it stuck somehow.
    - beng-nl 10mo ago
      Yes, I find this one of the weird things about assembly - appending (or pretending?) a number means addition?! - even after many many years of occasionally reading/writing assembly, I’m never completely sure what these instructions do so I infer from context.
    - kragen 10mo ago
      Generally such constant offsets are record fields in intent, not array indices. (If they were array indices, they'd need to be variable offsets obtained from a register, not immediate constants.) It's reasonable to think of record fields as functions: .equ car, 0 .equ cdr, 8 .globl length length: test %rdi, %rdi # nil? jz 1f # return 0 mov cdr(%rdi), %rdi # recurse on tail of list call length inc %rax ret 1: xor %eax, %eax ret To avoid writing out all the field offsets by hand, ARM's old assembler and I think MASM come with a record-layout-definition thing built in, but gas's macro system is powerful enough to implement it without having it built into the assembler itself. It takes about 13 lines of code: http://canonical.org/~kragen/sw/dev3/mapfield.S http://canonical.org/~kragen/sw/dev3/mapfield.S Alternatively, on non-RISC architectures, where the immediate constant isn't constrained to a few bits, it can be the address of an array, and the (possibly scaled) register is an index into it. So you might have startindex(,%rdi,4) for the %rdi'th start index: .data startindex: .long 1024 .text .globl length length: mov (startindex+4)(,%rdi,4), %eax sub startindex(,%rdi,4), %eax ret If the PDP-11 assembler syntax had been defined to be similar to C or Pascal rather than Fortran or BASIC we would, as you say, have used startindex[%rdi,4]. This is not very popular nowadays both because it isn't RISC-compatible and because it isn't reentrant. AMD64 in particular is a kind of peculiar compromise—the immediate "offset" for startindex and endindex is 32 bits, even though the address space is 64 bits, so you could conceivably make this code fail to link by placing your data segment in the wrong place. (Despite stupid factionalist stuff, I think I come down on the side of preferring the Intel syntax over the AT&T syntax.)
  - miningape 10mo ago
    Mom, please come pick me up. These kids are scaring me.

Joker_vD 10mo ago

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 And all it really takes to support this is just adding a second (smaller) ALU on your chip to do addressing calculations.

andrepd 10mo ago
Would this matter for performance? You already have so many execution units that are actually difficult to keep fully fed even when decoding instructions and data at the speed of cache.
- gpderetta 10mo ago
  Yes. As Joker_vD hints on a sibling comment, this is what killed all the classic CISCs during the OoO transition except for x86 that lacks the more complex addressing modes (and the PPro was still considered a marvel of engineering that was assumed not to be possible).
rocqua 10mo ago
There's also a lot of specialized instructions like AES ones. But the main thing that makes x86 CISC to me is not the actual instruction set, but the byte encoding, and the complexity there.
- Joker_vD 10mo ago
  Eh, that's really just a side effect of almost 50 years of constant evolution from a 8-bit microprocessor. Take look at VAX [0], for instance: its instruction encoding is pretty clean yet it's an actual example of a CISC ISA that was impossible to speed up like, literally: DEC engineers tried very hard and concluded that making a truly pipelined & super-scalar implementation was basically impossible; so DEC had to move to Alpha. See [1] for more from John Mashey. Edit: the very, very compressed TL;DR is that if you do only one memory load (or one memory load + store back into this exact location) per instruction, it scales fine. But the moment you start doing chained loads, with pre- and post-increments which are supposed to write back changed values into the memory and be visible, and you have several memory sources, and your memory model is actually "strong consistency", well, you're in a world of pain. [0] https://minnie.tuhs.org/CompArch/Resources/webext3.pdf https://minnie.tuhs.org/CompArch/Resources/webext3.pdf [1] https://yarchive.net/comp/vax.html https://yarchive.net/comp/vax.html

pansa2 10mo ago

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

andrepd 10mo ago
Funny to see a comment on HN raising this exact point, when just ~2 hours ago I was writing inline asm that used `lea` precisely to preserve the carry flag before a jump table! :)
- MYEUHD 10mo ago
  I'm curious, what are you working on that requires writing inline assembly?
  - veltas 10mo ago
    I'm not them but whenever I've used it it's been for arch specific features like adding a debug breakpoint, synchronization, using system registers, etc. Never for performance. If I wanted to hand optimise code I'd be more likely to use SIMD intrinsics, play with C until the compiler does the right thing, or write the entire function in a separate asm file for better highlighting and easier handing of state at ABI boundary rather than mid-function like the carry flags mentioned above.
    - vlovich123 10mo ago
      Generally inline assembly is much easier these days as a) the compiler can see into it and make optimizations b) you don’t have to worry about calling conventions
      - Someone 10mo ago
        > the compiler can see into it and make optimizations Those writing assembler typically/often think/know they can do better than the compiler. That means that isn’t necessarily a good thing. (Similarly, veltas comment above about “play with C until the compiler does the right thing” is brittle. You don’t even need to change compiler flags to make it suddenly not do the right thing anymore (on the other hand, when compiling for a different version of the CPU architecture, the compiler can fix things, too)

sethops1 10mo ago

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

mattgodbolt 10mo ago
My nefarious plan has been exposed!!
- EdwardDiego 10mo ago
  I hope you have a moustache you can twiddle while saying this. Possibly followed by a "Nyah!"
Sophira 10mo ago
People were probably already tricked into learning assembly when they played Human Resource Machine. A lot of people think it's a "teaching programming" game, and it sorta is, but it's actually teaching assembly language skills!

Thorrez 10mo ago

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

Joker_vD 10mo ago
(Almost) any instruction on x64 that writes to a 32-bit register as destination, writes the lower 32-bits of the value into the lower 32 bits of the full 64-bit register and zeroes out the upper 32 bits of the full register. He touched on it in his previous note "why xor eax, eax". But the funny thing is, the x64-specific supplement for SysV ABI doesn't actually specify whether the top bits should be zeroes or not (and so, if the compiler could rely on e.g. function returning ints to have upper 32 bits zeroes, or those could be garbage), and historically GCC and Clang diverged in their behaviour.
201984 10mo ago
He's actually wrong on the ABI requiring the top bits to be 0. It only requires that the bottom 32 bits match the parameter, but the top bits of a 32-bit parameter passed in a 64-bit register can be anything (at least on Linux). You can see that in this godbolt example: https://godbolt.org/z/M1ze74Gh6 https://godbolt.org/z/M1ze74Gh6 The reason the code in his post works is because the upper 32 bits of the parameters going into an addition can't affect the low 32 bits of the result, and he's only storing the low 32 bits.
- fweimer 10mo ago
  The LLVM x86-64 ABI requires the top bits to be zero. GCC treats them as undefined. Until a recent clarification, the x86-64 psABI made the upper bits undefined by omission only, which is why I think most people followed the GCC interpretation. https://github.com/llvm/llvm-project/issues/12579 https://github.com/llvm/llvm-project/issues/12579 https://groups.google.com/g/x86-64-abi/c/h7FFh30oS3s/m/Gksanh3WAAAJ https://groups.google.com/g/x86-64-abi/c/h7FFh30oS3s/m/Gksan... https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/61 https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/61

greatgib 10mo ago

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.

jfindper 10mo ago
It does make me curious about the what the super anti-ai people will do. Matt Godbolt is, obviously, extremely smart and has a lot of interesting insight as a domain expert. But... this was LLM-assisted. So, anyone who has previously said they'll never (knowingly) read anything that an ai has touched (or similar sentiment) are you going to skip this series? Make an exception?
- joaohaas 10mo ago
  I think most people wouldn't call proof-reading 'assistance'. As in, if I ask a colleague to review my PR, I wouldn't say he assisted me. I've been throwing my PR diffs at Claude over the last few weeks. It spits a lot of useless or straight up wrong stuff, but sometimes among the insanity it manages to get one or another typo that a human missed, and between letting a bug pass or spending extra 10m per PR going through the nothingburguers Claude throws at me, I'd rather lose the 10m.
- themafia 10mo ago
  > what the super anti-ai people will do. Just not use it. I couldn't care less if other people spend hours prompt engineering to get something that approaches useful output. If they want their reputation staked on it's output that's on them. The results are already in and they're not pretty. I just personally think it's absurd to spend trillions of dollars and watts to create an advanced spell checker. Even more so to see this as a "revolution" of any sort or to not expect a new AI-winter once this bubble pops.
  - jfindper 10mo ago
    The question was about reading stuff ai touched, not using ai stuff. But I'm glad you could get that off your chest!

secondcoming 10mo ago

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.

trollbridge 10mo ago
LEA is the equivalent of & in C. It gives you the address of something. Fun question: what does the last line of this do? MOV BP,12 LEA AX,[BP] MOV BX,34 LEA AX,BX
- hota_mazi 10mo ago
  I think OP was just making a comment on the asymmetry of the syntax. Brackets [] are usually used to dereference. Why is this written lea eax, [rdi + rsi] instead of just lea eax, rdi + rsi ?
  - secondcoming 10mo ago
    Yes, that’s what I meant
    - HarHarVeryFunny 10mo ago
      LEA stands for Load Effective Address, so the syntax is as-if you're doing a memory access, but you are just getting the calculated address, not reading or writing to that address. LEA would normally be used for things like calculating address of an array element, or doing pointer math.
  - Y_Y 10mo ago
    The way I rationalize it is that you're getting the address of something. A raw address isn't what you want the address of, so you're doing something like &(*(rdi+rsi)).
  - jcranmer 10mo ago

dist-epoch 10mo ago

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.

adrian_b 10mo ago
The modern Intel/AMD CPUs have distinct ALUs (arithmetic-logic units, where additions and other integer operations are done; usually between 4 ALUs and 8 ALUs in recent CPUs) and AGUs (address generation units, where the complex addressing modes used in load/store/LEA are computed; usually 3 to 5 AGUs in recent CPUs). Modern CPUs can execute up to between 6 and 10 instructions within a clock cycle, and up to between 3 and 5 of those may be load and store instructions. So they have a set of execution units that allow the concurrent execution of a typical mix of instructions. Because a large fraction of the instructions generate load or store micro-operations, there are dedicated units for address computation, to not interfere with other concurrent operations.
- dist-epoch 10mo ago
  But can the frontend direct these computations based on what's available? If it sees 10 LEA instructions in a row, and it has 5 AGU units, can it dispatch 5 of those LEA instructions to other ALUs? Or is it guaranteed that a LEA instruction will always execute on an AGU, and an ADD instruction always on an ALU?
  - adrian_b 10mo ago
    This can vary from CPU model to CPU model. No recent Intel/AMD CPU executes directly LEA or other instructions, they are decoded into 1 or more micro-operations. The LEA instructions are typically decoded into either 1 or 2 micro-operations. The addressing modes that add 3 components are usually decoded into 2 micro-operations, like also the obsolete 16-bit addressing modes. The AGUs probably have some special forwarding paths for the results towards the load/store units, which do not exist in ALUs. So it is likely that 1 of the up to 2 LEA micro-operations are executed only in AGUs. On the other hand, when there are 2 micro-operations it is likely that 1 of them can be executed in any ALU. It is also possible for the micro-operations generated by a LEA to be different from those of actual load/store instructions, so that they may also be executed in ALUs. This is decided by the CPU designer and it would not be surprising if LEAs are processed differently in various CPU models.

tony-john12 10mo ago

[dead]

f311a 10mo ago

What's the current best resources to learn assembly? So that I can understand output of simple functions. I don't want to learn to write it properly, I just want to be able to understand on what's happening.

photochemsyn 10mo ago
https://godbolt.org/ https://godbolt.org/ You can select the assembly output (I like RISCV but you can pick ARM, x86, mips, etc with your choice of compiler) and write your own simple functions. Then put the original function and the assembly output into an LLM prompt window and ask for a line-by-line explanation. Also very useful to get a copy of Computer Organization and Design RISC-V Edition: The Hardware Software Interface, by Patterson and Hennessy.

stassats 10mo ago

The text mentions that it can also do multiplication but doesn't expand on that. E.g. for x * 5 gcc issues lea eax, [rdi+rdi*4].

xg15 10mo ago
It also says the multiplier must be one of 2, 4 or 8. So I guess this trick then only works for multiplication by 2, 3, 4, 5, 8 or 9?
- stassats 10mo ago
  The tricks to avoid multiplication (and division) are probably worth a whole post. x * 6: lea eax, [rdi+rdi*2] add eax, eax x * 7: lea eax, [0+rdi*8] sub eax, edi x * 11: lea eax, [rdi+rdi*4] lea eax, [rdi+rax*2] But with -Os you get imul eax, edi, 6 And on modern CPUs multiplication might not be actually all that slow (but there may be fewer multiply units).
  - mattgodbolt 10mo ago
    Hey now; let's not get ahead too far :) I'm trying to keep each one bite-sized...I don't think you'll be (too) disappointed at the next few episodes :)

mordechai9000 10mo ago

This triggers a vague memory of trying to figure out why my assembler (masm?) was outputting a LEA instead of a MOV. I can't remember why. Maybe LEA was more efficient, or MOV didn't really support the addressing mode and the assembler just quietly fixed it for you. In any case, I felt slightly betrayed by the assembler for silently outputting something I didn't tell it to.

HarHarVeryFunny 10mo ago
LEA and MOV are doing different things. LEA is just calculating the effective address, but MOV calculates the address then retrieves the value stored at that address. e.g. If base + (index * scale) + offset = 42, and the value at address 42 is 3, then: LEA rax, [base + index * scale + offset] will set rax = 42 MOV rax, [base + index * scale + offset] will set rax = 3
- dataflow 10mo ago
  I assumed they're referring to register-register moves?
  - HarHarVeryFunny 10mo ago
    OK, so: LEA eax, [ebx] instead of: MOV eax, ebx But of course: MOV eax, [ebx] is not the same.

xjm 10mo ago

Part of the Advent of Compiler Optimisations https://xania.org/AoCO2025 https://xania.org/AoCO2025 Loving it so far!

egurns 10mo ago

> Yesterday we saw how compilers zero registers efficiently. It took several tries to understand zero is a verb

gbacon 10mo ago
Verbing weirds language.
- deleted 10mo ago
  [deleted]
- pwdisswordfishy 10mo ago
  Zero-suffixing does weird language.
- mattgodbolt 10mo ago
  Tell me about it...someone turned my name into a verb...
delta_p_delta_x 10mo ago
It might have been a little bit clearer to say: Yesterday we saw how compilers zero out registers efficiently. Or better still: Yesterday we saw how compilers set the values in registers to zero efficiently.
kragen 10mo ago
Often I use "zeroize" rather than "zero" to avoid such confusion.

zahlman 10mo ago

It's still wild to me that "Godbolt" is an actual surname.

xg15 10mo ago
Someone had a very talented archer as an ancestor.

badmonster 10mo ago

[flagged]

kragen 10mo ago
Human assembly programmers on the 8086 used LEA all the fucking time. And I'm not sure good ISA design is characterized by the need for ingenious hacks to get the best mileage out of the hardware; rather the opposite, in my view. The ARM2's ISA design is head and shoulders better than the 8086's.

sparkie 10mo ago

> x86 is unusual in mostly having a maximum of two operands per instruction[2] Perhaps interesting for those who aren't up to date, the recent APX extension allows 3-operand versions of most of the ALU instructions with a new data destination, so we don't need to use temporary registers - making them more RISC-like. The downside is they're EVEX encoded, which adds a 4-byte prefix to the instruction. It's still cheaper to use `lea` for an addition, but now we will be able to do things like or rax, rdx, rcx https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html https://www.intel.com/content/www/us/en/developer/articles/t...

jxors 10mo ago

> However, in this case it doesn’t matter; those top bits are discarded when the result is written to the 32-bit eax. Fun (but useless) fact: This being x86, of course there are at least three different ways [1] to encode this instruction: the way it was shown, with an address size override prefix (giving `lea eax, [edi+esi]`), or with both a REX prefix and an address size override prefix (giving `lea rax, [edi+esi]`). And if you have a segment with base=0 around you can also add in a segment for fun: `lea rax, cs:[edi+esi]` [1]: not counting redundant prefixes and different ModRMs

Aaron2222 10mo ago

This trick is something we teach our students when we do 6809 assembly (mainly as a trick to do addition on the index registers). I had no idea it was used as an optimisation in x86.