Related articles |
---|
Re: Q: P6 branch prediction krste@ICSI.Berkeley.EDU (1996-04-29) |
Re: Q: P6 branch prediction conway@rimmer.cs.mu.OZ.AU (1996-05-01) |
Re: Q: P6 branch prediction khays@sequent.com (1996-05-14) |
Re: Using memory below the SP (Was: Q: P6 branch prediction) zalman@macromedia.com (1996-05-18) |
Re: Using memory above TOS bart@time.cirl.uoregon.edu (1996-05-19) |
Using memory above TOS fjh@cs.mu.OZ.AU (Fergus Henderson) (1996-05-21) |
Re: Using memory below the SP (Was: Q: P6 branch prediction) meissner@cygnus.com (Michael Meissner) (1996-05-24) |
Re: Using memory above TOS markt@harlequin.co.uk (1996-05-29) |
From: | khays@sequent.com (Kirk Hays) |
Newsgroups: | comp.arch,comp.compilers |
Date: | 14 May 1996 20:21:36 -0400 |
Organization: | Sequent Computer Systems Inc. |
References: | <3179B05D.2781@cs.princeton.edu> <4m6ufs$msc@mulga.cs.mu.OZ.AU> 96-05-012 |
Keywords: | architecture |
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 <conway@rimmer.cs.mu.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
>live.
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
continuation.
This is not a safe optimization on most architectures, IOW.
--
Kirk Hays
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.