Assembly Is Too High Level: SIB Doubles | Hacker News Reader

Assembly Is Too High Level: SIB Doubles

xlogicx.net

62 pointsingve16 comments

The cool thing about the address calculation is that there is a LEA instruction (load effective address), which gives you the resulting address. I.e. instead of actually loading the value from the calculated address in memory, it gives you the address itself without accessing memory. This allows you to do "complex" calculations in just one instruction. This doesn't really help performance-wise in modern CPUs, but it used to in the old 386 days.

Yes, a lot of these let's call them `assembler hacks' were true at one time in the x86 32 bit era but are probably not true now. Also, the x86 processor market is quite big now from Pentiums and Core Ms and Core Is and AMD and god knows who else. There used to be assembler books that could teach you all this in the 32 bit era, do these exist for the 64 bit era. It's been a while since I did any low-level bit twiddling.

Agner Fog's PDFs are the closest thing I know of

gcc generates lea instructions still because `lea eax [eax*5]' is a lot shorter than whatever the machine code for multiplying by 5 is.

> This doesn't really help performance-wise in modern CPUs, but it used to in the old 386 days.

It might if it lets the compiler eliminate temporaries and thereby avoid register spills. This is less important on x86-64, though.

lea also doesn't set any flags which can be pretty useful when interleaving arithmetic operations with other things.

LEA is extremely useful on x86-64 for a different reason: it lets you determine your program counter.

For example, imagine you have code like this:

  static int foo;
  int *func(void) { return &foo; }

If you build it as position-independent code, on x86-64, you get:

  leaq	foo(%rip), %rax
  ret

Here, "foo" turns into the offset from the end of the LEA instruction to the variable foo. The x86 address calculation engine does the rest.

On x86-32, there's no IP-relative addressing, so you can't use LEA like this, and you get a mess, which I've trimmed into readability:

  ; x86-32 has no instruction that reads EIP.  Fake it.
  __x86.get_pc_thunk.ax:
  	movl	(%esp), %eax
  	ret
  
  func:
        call    __x86.get_pc_thunk.ax ; <-- this sucks
        addl    $_GLOBAL_OFFSET_TABLE_, %eax
        leal    foo@GOTOFF(%eax), %eax  <-- ???
        ret

I don't know why this is as indirect as it is on x86-32, but this really is what gcc generates. The ??? is a GOT reference.

Edit: fixed formatting

> I don't know why this is as indirect as it is on x86-32, but this really is what gcc generates.

Possibly because the ELF relocs require that exact instruction sequence.

I would say you cannot deduce much from that micro-benchmark. On x86, loops depend on the alignment of the labels and branch instructions due to the branch prediction logic. You can actually make some loops faster by inserting nops inside the loop.

Since the result of the xor is never read and immediately overwritten by the following mov, I wonder if clever register renaming could actually detect that and discard the instruction.

Yes, I'm also suspicious about his claims of "this is faster than that." He doesn't demonstrate that the actually know how something like this should be correctly measured.

My first thought was: is this a caching / instruction-fetch artifact? The two instruction sequences generate blocks of 8 bytes (for the eax+eax version) vs 11 bytes (for the 2*eax +0 version).

That's just about the only possibility, I think -- both forms should generate the same sequence of uops.

Could someone inform an old fogey if "super ignorant" (down at the end of the article) means that something is actually very good?

Oh, and cool article btw. I think I have a hazy recollection from a long long time ago Microsoft assembler would do the same -- as in pick the smallest machine opcode in the case of multiple assembler possibilities.

A lot of assemblers did that. Which is why in self-modifying code you inserted an instruction to load a large integer constant (e.g. 0xDEADBEEF) that the assembler could not optimize into a smaller instruction. Then at runtime you would replace that integer constant with whatever value, without the risk of overwriting part of the next instruction.

Those were the days...

Indeed. The bubbles virus really confused me the first time I stepped through a self modifying section using dos's debug program.

This guy needs an ontology.

Reply on news.ycombinator.com