setjmp/longjmp implementations

hbaker@netcom.com (Henry G. Baker)
Wed, 16 Feb 1994 01:52:29 GMT

          From comp.compilers
Related articles
setjmp/longjmp implementations hbaker@netcom.com (1994-02-16)
Re: setjmp/longjmp implementations chase@Think.COM (1994-02-16)
Summary of setjmp/longjmp responses hbaker@netcom.com (1994-02-17)
Re: setjmp/longjmp implementations pardo@cs.washington.edu (1994-02-17)
Threads (WAS: setjmp/longjmp implementations) pardo@cs.washington.edu (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)
[2 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Followup-To: hbaker@netcom.com
Summary: How fast and/or optimized are they
Keywords: C, question, optimize
Organization: nil
Date: Wed, 16 Feb 1994 01:52:29 GMT

I have been working on a portable program in which longjmp is executed
frequently enough to be a possible bottleneck. I was wondering about the
efficiency of existing implementations.


Do setjmp or longjmp occur in any of the standard -- e.g., SPEC --
benchmarks?


Do compiler writers stay up nights worrying about the speed of their
implementation?


Has anyone ever lost a sale due to poor setjmp/longjmp performance?


Do compilers even notice when setjmp or longjmp occur in their programs?
E.g., the statement after longjmp isn't likely to be executed if it
doesn't have a label.


Are any longjmp's open-coded?


Does anyone know how fast his implementation of setjmp or longjmp is?


I know that setjmp/longjmp are not just for exceptions, anymore.
Apparently, longjmp implementations which checked for jumping 'up' the
stack were criticized by those using setjmp/longjmp for stack switching in
a multiple process environment. If someone is really doing time-sharing
using setjmp/longjmp--e.g., taking a 60Hz interrupt-- then he's going to
start worrying about overheads.


A related question is whether global statics have to be declared
'volatile'. The ANSI document gives the impression that one doesn't have
to do this, but implementations that care about such things seem to die if
static globals are not declared 'volatile'.


I found that '_setjmp'/'_longjmp' of gcc were a bit faster on the Sun.


    -- Henry Baker
          hbaker@netcom.com
          "Take a longjmp off a short stack."
--

Post a followup to this message

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