Re: Summary of setjmp/longjmp responses

hbaker@netcom.com (Henry G. Baker) writes:
|> 5. Sparc register windows are a major pain in the butt. longjmp
|> apparently traps to flush out the contents of all of its registers,
|> even if they are all dead. [This sounds like an excellent time for
|> the compiler to help.]


This is Sun's mistake and has nothing to do with the compiler. Also, the
statement above is incorrect as well.


(1) The register flush windows trap executes n save instructions followed
by n restore instruction. The actual number is determined by the number of
register windows of the processor. (I think n = #windows-2).


(2) If and only if a save instruction results in an register overflow
trap, a frame will be saved on stack. There may be as many as n overflow
traps and as few as 0. Thus, it is NOT true that all windows are saved on
stack. Only those windows which are not already saved on stack, will be
saved.


(3) The compiler cannot influence which register windows are saved since
this information is stored in the processor status register which is only
accessible in supervisor mode. This is the very reason that flushing
registers is implemented as a trap instruction (which executes in
supervisor mode).


(4) Sun did not do the best job on flushing register windows. Rather than
executing n save and n restores which cause traps themselves, one can
explicitly save only those register windows which are not already on
stack. This avoids the overhead of (up to) n traps and enabling/disabling
traps (and some more instructions become redundant).


I have written such code for a stand-alone micro kernel (under POSIX
minimal real-time profile) and it runs faster than the Sun code (which is
not surprising). In fact, it should be possible to "patch" this code into
any SunOS release as it only modifies the register flush windows trap.
(But I haven't tried yet.)


(5) The SPARC register windows are a pain in the butt. Anybody who has
programmed at the level of traps and hardware interrupts should be able to
second this. And they cannot be directly manipulated by the compiler. On
the other hand, caller-save / callee-save does not have to be implemented
since the window take care of it automatically. (Of course, you lose
control over registers and cannot reduce the register save overhead were
few registers need to be saved.)


Frank
mueller@cs.fsu.edu
--

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