[fa.info-vax] CLU on uVAX-II

info-vax@ucbvax.ARPA (05/14/85)

From: rws@mit-bold

The existing VAX 4.2 version of CLU does not run reliably on a uVAX-II under
Ultrix.  There is a new version of CLU that fixes the problem.  Those wanting
to use CLU under Ultrix on a uVAX-II should get a new distribution (for $50)
from me.

The problem is that, on an instruction emulation trap, the USER stack is used
to perform the emulation.  In the 4.2 environment, this makes it not a true
emulation, at least in my opinion (but the II is such a winner in other
respects I'm not going to complain too much).  There are no other cases
where the system scribbles in user memory.  There is no written law, as there
is in VMS, that the contents of memory beyond the current SP must be
considered undefined.  The only 4.2 mechanism that comes close is the signal
mechanism, which uses the user stack.  However, 4.2 has the sigstack mechanism
for this very reason (actually the 4.2 implementation still trashes part of
the user stack, but this bug is fixed in 4.3).  In fact, there is no written
law that the user SP must be valid at all times under 4.2; one can mask all
signals during critical sections where SP is invalid.

The CLU implementation relies on controlling memory contents to make garbage
collection possible and normal execution fast.  In particular, we allocate
local variable space in a stack frame by simply bumping SP, relying on the
memory contents, while "random", to be valid as far as garbage collection is
concerned.  We guarantee this, at least on all other VAX processors, by using
a separate, non-garbage-collected stack for all signal handling, and by
clearing out memory beyond SP during a garbage collecton.  (CLU uses a fixed
size stack.)

The fix we have adopted is to switch to a non-garbage-collected "emulation
stack" for the duration of a possibly emulated instruction (principally the
string instructions).  This adds three (sometimes four) instructions of
overhead to these instructions.  Since string instructions aren't used that
much by most programs, the additional overhead is fairly small on non-uVAX
processors.  (The worst I have measured so far on a 750 is 4.5%.)