Re: Stack frames
From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 11/17/04
- Next message: Randall Hyde: "Re: Memory Management"
- Previous message: Squeek: "Re: Looking for a tech reviewer"
- In reply to: C: "Stack frames"
- Next in thread: C: "Re: Stack frames"
- Reply: C: "Re: Stack frames"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 17 Nov 2004 05:35:50 GMT
"C" <cc-news@hermes.mirlex.com> wrote in message
news:17omd.436$Ro4.300@newsfe6-gui.ntli.net...
> Hello folks,
>
> Procedure prologue would consist of...
>
> proc_entry:
> SUB esp, size( locals + align )
> PUSH dword [ esp + size( locals + align ) ]
>
> (This would be unneeded and could be reduced
> if no locals are used and the stack is
> aligned.) Procedure epilogue would consist of...
>
> RET size( params + 4 + locals + align )
>
> No penalties should occur with return
> prediction, as happens when replacing "RET"
> with "JMP <loc>", or the stalls in reading
> ESP with the common stack frame models.
> So this design should be faster than the
> current methods, ...
>
> ADD esp, size( locals + align )
> RET size( params )
>
> Or...
>
> MOV ESP, EBP
> RET size( params )
Have you tested this idea to prove it provides
a reasonable performance boost?
Granted, the return is simpler, but setting up the
activation record in the first place may very well
cost you more. As for stalls associated with reading
ESP, why not simply move the "MOV esp, ebp"
instruction elsewhere, if this is a problem?
> With the additional benifits that the EBP
> register remains unused and the stack is
> always aligned to 16 bytes.
Of course, be careful of those pushes and pops
in your code prior to a call (e.g., register preservation).
You can't rely on "size( locals + align )" to keep the
stack 16-byte aligned unless you know for a fact
it was 16-byte aligned to begin with.
A static analysis of the code won't work here, because
ESP could contain different values at a given point in the
code depending on the path through the code to that point.
I've not bothered counting cycles for a while, but I wonder
if the PUSH instruction (that duplicates the return address)
is really going to be that much faster than the "mov esp,ebp",
even with a stall.
>
> (Intel's P4 optimisation manual recommends
> stack alignment is done as follows, ...
>
> prologue:
> SUB ESP, 4
> MOV [ESP], EBP
> MOV EBP, ESP
> AND EBP, ~15
> MOV [EBP], ESP
> SUB ESP, size( FRAME )
> ;; proc
> epilogue:
> MOV ESP, [EBP]
> MOV EBP, [ESP]
> ADD ESP, 4
> RET
>
> I think we can see the proposed design is
> more efficient than that, provided it is
> used throughout the application.
Note the "AND EBP, ~15" instruction.
This guy is *very* important. That's how you
guarantee 16-byte alignment. I don't see how
your code does this -- maybe I'm just missing
something.
>
> Stack unwinding, where necessary, could be
> done via a header before the procedure which
> notes the number of bytes needing removing
> [ == size( params + 4 + locals + align ) ],
> the limits of the procedure, and maybe a
> cleanup or catch routine. However, this
> feature is unlikly to interface will with
> existing HLLs, each of which have their own
> method of stack unwinding.
Of course, such a scheme is going to be incompatible
with other languages. That's not particularly important.
When you interface with other languages, you have to
use their activation record layout, you have no choice.
But for the pure assembly procedures, feel free to
do anything you like, as long as you keep in consistent.
One other comment--
If you're indexing off ESP, you lose some range on
the maximum number of local variables you can access
with a single byte displacement and if you have a large
number of local variables, you cannot access your
parameters using one-byte displacements. Something
to keep in mind.
Cheers,
Randy Hyde
- Next message: Randall Hyde: "Re: Memory Management"
- Previous message: Squeek: "Re: Looking for a tech reviewer"
- In reply to: C: "Stack frames"
- Next in thread: C: "Re: Stack frames"
- Reply: C: "Re: Stack frames"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
