register volatile (was The world is not ready for 'volatile')

[Chris Torek]

In article <184 at microsoft.UUCP> w-colinp at microsoft.UUCP (Colin Plumb) writes:
>I can think of at least one example of a register volatile variable, if
>you're playing with setjmp/longjmp.

This is the weak spot in my `useless' argument.  It would not come up
if X3J11 had not done such a horrid thing with setjmp/longjmp; and
remember that I was arguing from an `if things were slightly different'
viewpoint.  (If things were different, they would be different, so there
is not too much reason to keep arguing.  But things could be slightly
different and still consistent----which is all I ever meant to say!)

>"Register volatile x" tells the compiler to try and store it somewhere
>quick, but safe from setjmp/longjmp.  In most compilers, this would
>basically turn off the register declaration, but in transputer compilers
>I've used, "register" tells the compiler to keep the value in the 16 words
>nearest the stack pointer, which are especially quick to access.  Here,
>register and volatile both mean something.
>
>Can anyone poke holes in this example?

(Aside from the `if (y = 0)' that should have been `if (y == 0)' :-) )

For portable code, you must avoid `register volatile', because current
systems (not dpANS-conformant, but still useful, such as SunOS) will
use something like

	#define volatile /*empty*/

and will see

	register /*empty*/ int x;

and will do what I described earlier (restore x to the value it had
at the call to setjmp()), whereas if you write

	volatile int x;

the compiler will see

	/*empty*/ int x;

and will do the `right thing'.

If you are not interested in running under pre-ANSI compilers, you
may ignore this argument.  (But calls to setjmp() are rare enough that
I, for one, intend never to use any register variables around setjmp().)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris