|Re: Q: P6 branch prediction krste@ICSI.Berkeley.EDU (1996-04-29)|
|Re: Q: P6 branch prediction email@example.com.OZ.AU (1996-05-01)|
|Re: Q: P6 branch prediction firstname.lastname@example.org (1996-05-14)|
|Re: Using memory below the SP (Was: Q: P6 branch prediction) email@example.com (1996-05-18)|
|Re: Using memory above TOS firstname.lastname@example.org (1996-05-19)|
|Using memory above TOS email@example.com.OZ.AU (Fergus Henderson) (1996-05-21)|
|Re: Using memory below the SP (Was: Q: P6 branch prediction) firstname.lastname@example.org (Michael Meissner) (1996-05-24)|
|Re: Using memory above TOS email@example.com (1996-05-29)|
|From:||firstname.lastname@example.org (Kirk Hays)|
|Date:||14 May 1996 20:21:36 -0400|
|Organization:||Sequent Computer Systems Inc.|
|References:||<3179B05D.email@example.com> <firstname.lastname@example.org.OZ.AU> 96-05-012|
krste@ICSI.Berkeley.EDU (Krste Asanovic) writes:
>A related often-missed optimization is delaying the build of a stack
>frame until it is certain it is needed. [...]
>Can any current compilers do this optimization?
Thomas Charles CONWAY <email@example.com.OZ.AU> wrote:
>To avoid wasting the cycle, what the Mercury compiler now does is emit
>code to save the return continuation one slot above the stack top,
>then the conditional branch and then, in the appropriate arm of the
>code, the stack pointer increment. Because the store of the return
>continuation is above the stack top, it doesn't clobber anything
Am I correct in assuming interrupts and faults are not an issue
on this machine?
If they are, and you take an interrupt or fault between the time the
information is stored above the stack top, and when the stack pointer
is finally incremented, you'll have garbaged the stored return
This is not a safe optimization on most architectures, IOW.
Return to the
Search the comp.compilers archives again.