In message <[EMAIL PROTECTED]>, intmktg@
CAM.ORG writes:
>Perhaps, but no matter the degree of optimisation, the
>16 byte of space is performed in two instructions. This
>leads me to believe is it most likely a pipelining issue
>for the following pushl instructions. As for subl'ing and
>addl'ing 8 bytes instead of 4, as required by each pushl,
>that can very well be an aligning issue which would seem
>to make more sense for the x86.
pushl puts the operand on the stack and then decrements %esp
by an appropriate quantity.
Nothing needs to be done to the stack before it.
My best guess (if it isn't a bug) would be that it's there to keep the stack
on a 32 byte (IIRC, this sounds like cache line size for the newer
Intel chips) boundary when the program gets to open (4 for saved %ebp, 4
for the char * arg, 4 for the int arg, and 4 for the %eip call pushes
requires 16 bytes more to preserve a 32 byte alignment) so that in a
"normal" function without a lot of locals all of the locals are on the
same cache line.
Two instructions instead of 1 would help to facilitate alignment of the
return address (I think 16 bytes is a good alignment for a jmp, and
I can't see why a ret wouldn't the same), and a subl + addl combination
would prevent interferance by a stupid peephole optimizer looking to
combine addls with the same destination register.
--
<a href="http://www.poohsticks.org/drew/">Home Page</a>
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
