Re: Semaphore assembly-code bug

[Andreas Steinmetz]

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/