Re: Using memory below the SP (Was: Q: P6 branch prediction)

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.


khays@sequent.com (Kirk Hays) wrote:
> 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.


Using the IBM calling convention on PowerPC, the 64 bytes immediately
below the stack pointer (that is just outside the stack region) are
guaranteed to be useable by a fucntion. This gives a function access
to a small amount of memory without the expense of buying a stack
frame. So on that platform, this technique is undeniably safe.


But I expect one doesn't even need that to get the optimization Thomas
describes to work reliably. Most OSes don't use the user stack space
to handle interrupts or for running the kernel code that handles a
fault. Rather they use an alternate stack. (E.g. the kernel stack in
the U area of a UNIX process.) This is done for security and
reliabilty reasons as one has no idea what a user process has stuffed
in the stack pointer register.


That leaves asynchronous events delivered to the user process
e.g. UNIX signals. With a BSDish UNIX, one can assign an alternate
stack to be used for signal delivery (on a per signal type basis as I
recall). If all async signals are put on a different stack, one
doesn't have to worry about any bytes in the main stack region
changing without "compiler knowledge." Hence the optimization given
is safe.


Zalman Stern, Caveman Programmer, Macromedia Video Products, (415) 378 4539
3 Waters Dr. #100, San Mateo CA, 94403, zalman@macromedia.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.