Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caesar.cs.montana.edu!milton!uw-beaver!zephyr.ens.tek.com!tekfdi!videovax!bart
From: bart@videovax.tv.tek.com (Bart Massey)
Newsgroups: comp.lang.perl
Subject: Re: Bugs in perl 3.0 pl 8 -- return statement
Message-ID: <5720@videovax.tv.tek.com>
Date: 16 Feb 90 10:33:48 GMT
References: <4080004@hpausla.aso.hp.com> <4080005@hpausla.aso.hp.com> <418@proexam.UUCP> <7000@jpl-devvax.JPL.NASA.GOV> <TOM.90Feb9070637@hcx2.ssd.csd.harris.com> <7068@jpl-devvax.JPL.NASA.GOV> <5716@videovax.tv.tek.com> <7080@jpl-devvax.JPL.NASA.GOV> <1990Feb15.2022
Reply-To: bart@videovax.tv.tek.com (Bart Massey)
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 41

In article <1990Feb15.202214.14987@umn-cs.cs.umn.edu> mike@umn-cs.cs.umn.edu (Mike Haertel) writes:
> In article <7080@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
> >Ok, I'll spread a few more judicious volatiles here and there on my globals
> >and structure elements.  Blech.  All this gobblygook just to make life
> >a little easier for a few compiler writers.  setjmp()/longjmp() are NOT
> >in the same class as asynchronous interrupts.
> >
> >"volatile" must go.  This is non-negotiable.    :-) :-) :-)
> 
> Note that if -traditional is used with gcc, it automatically recognizes
> functions that call setjmp() and effectively forces all references from
> within those functions to be volatile.
> 
> Of course, particularly if you call setjmp() from somewhere within
> a big, oft-used function, this is an efficiency hit, so volatile
> declarations may be more appropriate, if more work.

This whole discussion probably belongs somewhere else, but I couldn't resist
one last word.  The problem, as Mike points out, is not the "volatile"
keyword, which is a serious feature for those of us writing memory-mapped
device drivers.  The problem is the gratuituous, superfluous, and altogether
obnoxious change by the ANSI folks of the most common traditional semantics
of setjmp() .  Under BSD Unix, at any rate, unless you call _setjmp(), you
get a *system call* anyway, to save the signal mask as well as the machine
state.  What ANSI *should* have done, IMHO, is to specify setjmp() and
longjmp() to save all auto variables, and _setjmp() and _longjmp() to have
the current more efficient but less comprehensible and useful semantics.

The perceived problem is that old-style setjmp() forces either the save of
essentially the entire machine state, including possibly a gazillion
registers, or implementation of setjmp() as compiler builtins.  My claim is
that the cost of saving the machine state is swamped on many UNIX machines by
the cost of the system call, and that it wouldn't be that hard to implement
setjmp() and longjmp() as compiler builtins which save the live state and
call a library routine, as I assume GCC does based on Mike's comments above.

Please don't take away my "volatile"! :-)

					Bart Massey
					..tektronix!videovax.tv.tek.com!bart
					..tektronix!reed.bitnet!bart