Re: Using memory above TOS

Thomas Charles CONWAY <conway@rimmer.cs.mu.OZ.AU> wrote that
the Mercury compiler uses an optimization that depends on a
word above TOS (the Top Of the Stack) not being munged.


khays@sequent.com (Kirk Hays) wrote:
> Am I correct in assuming interrupts and faults are not an issue
> on this machine?


Zalman Stern <zalman@macromedia.com> wrote:
> 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.


IMHO this isn't very "safe". First, I'm not real sure I want
my (e.g.) C compiler to be usable only with BSD-style versions
of UNIX. Second, and more importantly, depending on an
alternate signal stack means that the compiler has to set up
such a stack before the program can start (presumably in crt0).
Finally, the user now has a very difficult time writing signal
handlers in C, especially ones that want their own signal
stack. All this can probably be made to work, but I'd be
somewhat afraid of such a C compiler.


For a language like Mercury, in which there's an explicit
runtime system and signal handlers are not directly implemented
by the user, optimizations which use memory above TOS may be
acceptable. Even there, however, I'd have to see some pretty
large performance improvements, and convince myself they could
be achieved only by using memory above TOS, before I would
think it was worth it.


FWIW, I briefly considered such an optimization for our "Super
Monaco" compiler (for a language similar to Mercury), but
rejected it partly for the reasons given above.


Bart Massey
bart@cs.uoregon.edu


P.S. -- Actually, now that I think about it, the main reason I
avoided memory above TOS is that I wasn't sure that UNIX
promised to keep pages above TOS backed up in VM; i.e., if TOS
was sitting at a page boundary, the page above might be paged
out at an arbitrary time, and then be reallocated zero-filled
when next referenced, losing the contents of words above TOS.
(I know that some UNIXes (Unices?) don't have demand-allocated
VM stacks, in which case this problem presumably doesn't
arise.) Am I just being paranoid?


[Unixes I've looked at allocate stack pages when the stack pointer grows down
to them, then treats the stack pages the same as any other. It'd be a be
reasonable to discard pages beyond the stack pointer, though I've never seen
a system that did, most likely because a program that used to have a large
stack will probably have one again soon. -John]


--

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