Summary of setjmp/longjmp responses

Thanks to those who responded re my setjmp/longjmp questions.


Here is the consensus of these respondents:


1. No commonly used benchmarks depend upon setjmp/longjmp performance.
[If this is so, I'm amazed that setjmp/longjmp work at all! :-). ]


2. setjmp has to save registers, longjmp has to restore them. The more
live registers, the worse performance. Callee save can win here.


3. Most Unix implementations of setjmp/longjmp save/restore signal
masks. Therefore, use _setjmp/_longjmp if you don't care about this.
[I found substantial -- at least 10-20% savings -- from using the
underlined versions.)


4. There are actually a few compilers that know about setjmp/longjmp
and try to do something decent -- Semantec Think C/C++, Gnu, ATT
Plan9, Sequent.


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.]


6. Alpha longjmp appears to trap to do something or other, but
_longjmp does not.


7. The MIPS 4000 implementations seem to do the right thing without
any fuss and bother.


8. No experience with HP.


9. No one can figure out what the ANSI standard intends
w.r.t. volatile globals and setjmp/longjmp. [Responses differed,
indicating severe lack of clarity in ANSI standard.]


Thanks to:
Mark Orton, Claus Gittinger, Manuel Serrano, Bakul Shah, Marlin Prowell,
Bruno Haible, Bart Massey, paulw@att.
(I hope that I didn't leave anyone out.)


  -- Henry Baker
        hbaker@netcom.com
--

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