[net.lang.c] Volatile type in ANSI C

brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/24/85)

Looking at the description for the volatile type in the draft of the
ANSI C standard there seems to be some incompleteness.
The volatile type could have uses in multiprocessing where several
processors share some data areas.  One could have volatile pointers to
non volatile data areas (rarely) and more frequently nonvolatile pointers
to volatile data areas that are shared with other processors.
Does the ANSI C standard address these issues?

One certainly ought to have a non volatile pointer to a volatile storage
area.  The declaration

register volatile int *pint;

is a good example.  A register pointer, which can't possibly be volatile,
is used to point to a volatile storage area.  On each access to the pointed
to int one wants to actually do the memory operation and not allow cacheing
of the integer value in another machine register.

One would certainly have uses for the above when multiprocessing.  The
the other case, a volatile pointer to a non volatile int, does not have
any utility that is clear to me but who knows when someone might find a use
for one.

If ANSI C is going to add a new type to the language defintion shouldn't
we carfully consider all the applications of it and make sure the addition
to the language will take care of all the possible uses?

gamma@rtp47.UUCP (Michael Meissner) (04/26/85)

Both flavors of volatile have their uses:

    1)	volatile int *p;	/* p is a non-volatile ptr to volatile mem */
		The compiler can optimize `p' into a register, or some such,
		but every access to the memory p points to cannot be optimized.

    2)	int * volatile q;	/* q is a volatile ptr to non-volatile mem */
		This is useful for things like multi-processor implementations,
		where q can be modified at any time (though obviously you might
		get strange results if q is not aligned correctly, and the other
		processor takes more than 1 memory cycle to update q).  Because
		q is volitle, it means that anything it points cannot be
		optimized, and probably it should read:
			volatile int * volatile q;
	
	Michael Meissner
	Data General Corporation
	...ihnp4!mcnc!rti-sel!rtp47

henry@utzoo.UUCP (Henry Spencer) (04/28/85)

> Looking at the description for the volatile type in the draft of the
> ANSI C standard there seems to be some incompleteness.
> The volatile type could have uses in multiprocessing where several
> processors share some data areas.  One could have volatile pointers to
> non volatile data areas (rarely) and more frequently nonvolatile pointers
> to volatile data areas that are shared with other processors.
> Does the ANSI C standard address these issues?

Yes.  It provides both.  "volatile int *foo;" declares a nonvolatile
pointer to volatile; "int * volatile foo;" declares a volatile pointer
to nonvolatile.  (Excuse me a moment while I barf over the syntax.)
If you're really a masochist, "volatile int * volatile foo;" is a
volatile pointer to a volatile area.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

kjm@ut-ngp.UUCP (Ken Montgomery) (05/09/85)

>[henry@utzoo.UUCP (Henry Spencer)]
>
> ... It provides both.  "volatile int *foo;" declares a nonvolatile
>pointer to volatile; "int * volatile foo;" declares a volatile pointer
>to nonvolatile.  (Excuse me a moment while I barf over the syntax.)

What made me toss my cookies over this syntax is the apparent
inconsistency between the following:

1.  volatile int *foo;
2.  int * volatile foo;

In number 1, the _volatile_ immediately precedes the component of
the declaration corresponding to the volatile object (the _int_).
In number 2, the _volatile_ *follows* the corresponding component
(the _*_).  I find this inconsistency confusing; why doesn't the
_volatile_ always precede its corresponding component?  In other
words, number 2 would become:

2a. int volatile * foo;

I think this is a more consistent, and therefore superior, syntax.

--
The above viewpoints are mine.  They are unrelated to
those of anyone else, including my cats and my employer.

Ken Montgomery  "Shredder-of-hapless-smurfs"
...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm  [Usenet, when working]
kjm@ut-ngp.ARPA  [for Arpanauts only]