Re: Semaphore assembly-code bug
From: Andreas Steinmetz
Date: Fri Oct 29 2004 - 15:04:47 EST
Linus Torvalds wrote:
On Fri, 29 Oct 2004, Andreas Steinmetz wrote:
Linus Torvalds wrote:
Somebody should check what the Pentium M does. It might just notice that
"lea 4(%esp),%esp" is the same as "add 4 to esp", but it's entirely
possible that lea will confuse its stack engine logic and cause
stack-related address generation stalls..
Now especially Intel tells everybody in their Pentium Optimization
manuals to *use* lea whereever possible as this operation doesn't depend
on the ALU and is processed in other parts of the CPU.
Sample quote from said manual (P/N 248966-05):
"Use the lea instruction and the full range of addressing modes to do
address calculation"
Does it say this about %esp?
The stack pointer is SPECIAL, guys. It's special exactly because there is
potentially extra hardware in CPU's that track its value _independently_
of the actual physical register.
It doesn't say anything about esp being specially treated by the
underlying hardware as far as I can see. Thus either you know details
about the cpu not being publically available or you're speculating about
undocumented features.
Some more data from said manual (lea is better on P3 and the same as add
on P4):
Instruction Latency Execution Unit
ADD/SUB: 0.5 ALU
POP 1.5 MEM_LOAD,ALU
Now, a P4 had two ALUs (Ports 0 and 1) but only one MEM_LOAD Unit (Port
2). So after all you will be stalled more likely by an additional pop
instruction than by lea/add. I don't know about P4 internals but let me
make some guess: There's lot of software around that needs to run on
older processors where lea has quite some performance advantage. Thus I
would guess that the P4 design respects this by handling lea x(esp),esp
efficiently.
If you still believe in features I can't find any manufacturer
documentation for, well, you're Linus so it's your decision.
--
Andreas Steinmetz SPAMmers use robotrap@xxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/