LEA ESP, [ESP-4] vs. SUB ESP, 4

[CuriousKit]

Is there any reason, under Win32, why the Free Pascal compiler favours using "LEA ESP, [ESP-4]" (or "lea -0x4(%esp),%esp" in AT&T notation) over "SUB ESP, 4" when it comes to manipulating the stack pointer (in effect calling "PUSH" without actually writing a value to the stack, usually used to reserve a temporary variable for later)? The subtraction routine takes just as much space (3 bytes... 8d55fc for the LEA instruction and 83ec04 for the SUB instruction) but logically seems faster to compute as well as take advantage of the internal speed-ups on the CPU, or am I mistaken?

Not that I'm criticising the FPC compiler (and this is the wrong board for it), but I'm studying assembly language for the moments where I need to squeeze as much speed as I can out of the program.

[marcov]

(effective) Address calculation is a separate unit inside a processor. Could be that in older processors it allowed for a bit more parallelism, having ALUs and an address operation in parallel

And speed and size are not necessarily correlated.

[CuriousKit]

That makes some sense.  Indeed, speed and size aren't necessarily correlated, but wondered because it seems a bit overkill for a simple subtraction.  Thanks for the insight though.

[SymbolicFrank]

All current x86_64 CPUs are actually virtual machines that run x86_64 byte-code through a JIT interpreter.

[marcov]

All current x86_64 CPUs are actually virtual machines that run x86_64 byte-code through a JIT interpreter.

If you generalize that coarsely, you might as well say that humans are virtual machines on top of a DNA interpreter.

[SymbolicFrank]

I mean, the early machine code (4040 / 8080) was a pattern of switches that turned functional units in the CPU on and off. The second generation of CPUs (8086) used a demultiplexer first. So, there was a clear relation between the machine code and the functions performed.

The third generation (80286) used indexes instead of demultiplexers, and microcode for the complex instructions. Here, the instructions that are actually executed start to diverge from the binary ones.

The fourth (Pentium) translated it into micro-ops that ran on two RISC CPUs. There are multiple execution units (instruction decode, load / store, integer, floating point, SIMD). All those execution units have their own instruction set and there is a task manager.

The fifth (Pentium Pro / M) introduced Out-Of-Order execution, shadow registers and an instruction code optimizer. Or in other words: they virtualized the CPU.

The sixth (current) adds more and more cores and execution units on a single die, and it adds a complex memory manager for the cache memory.

The next generation is in 3D modules and package stacking. And hopefully better multi-task support. One of the main bottlenecks for Intel is memory consistency. If they think they can get rid of that between tasks, they will. That requires more virtualization and support for messaging.

[CuriousKit]

Very interesting.  I presume also that the virtualisation makes it easier to release bug fixes to an extent, like the crash that GIMPS discovered a couple of months ago, and the ability to disable things completely (like TSX) if it runs a bit deeper.

Back to the original question though... I can't see a particularly reliable way of determining which of the two commands is faster, since it's just one command and timings would be easily skewed by all sorts of things.  I would just blindly trust that the compiler programmers know best with their choice, although I would like to truly understand the reasoning, especially as it seems counterintuitive at first glance (you can't get much simpler than simple arithmetic, except maybe moving a value between two registers).

[SymbolicFrank]

The only way I know of to figure that out: compile it with an Intel compiler and set all optimizations to the max. It will probably do something completely different.

But that might not translate to older CPUs or AMD ones.