Summary of setjmp/longjmp responses

hbaker@netcom.com (Henry G. Baker)
Thu, 17 Feb 1994 18:28:25 GMT

          From comp.compilers

Related articles
setjmp/longjmp implementations hbaker@netcom.com (1994-02-16)
Summary of setjmp/longjmp responses hbaker@netcom.com (1994-02-17)
Re: Summary of setjmp/longjmp responses mueller@nu.cs.fsu.edu (1994-02-18)
Re: Summary of setjmp/longjmp responses pardo@cs.washington.edu (1994-02-18)
Summary of setjmp/longjmp responses meissner@osf.org (1994-02-22)
| List of all articles for this month |

Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Followup-To: hbaker@netcom.com
Keywords: C, summary
Organization: nil
References: 94-02-097
Date: Thu, 17 Feb 1994 18:28:25 GMT

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


Post a followup to this message

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