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]