vinoski@apollo.HP.COM (Stephen Vinoski) (05/22/91)
Several weeks ago someone was complaining that the Apollo Domain/C compiler gave bogus warnings about the function arguments specified as "volatile" in the file cmd.c, and wanted to know what they could do about it. It might be better to ask why those function arguments are specified as "volatile" in the first place. What exactly does it mean to specify function arguments as volatile? How can a stack location or a register be volatile, assuming the computer is operating correctly and the compiler generates proper code? The only reason I could come up with for making the arguments volatile would be to prevent some brain-damaged compiler from incorrectly optimizing references to them away. Can someone enlighten me? I personally think our compiler is right for barking about this strange usage of the "volatile" specifier. thanks, -steve | Steve Vinoski (508)256-0176 x5904 | Internet: vinoski@apollo.hp.com | | HP Apollo Division, Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski |
arielf@tasu8c.UUCP (Ariel Faigon) (05/22/91)
[This should probably go to comp.lang.c ...] +-- In article <51b2fae2.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: | Several weeks ago someone was complaining that the Apollo Domain/C | compiler gave bogus warnings about the function arguments specified as | "volatile" in the file cmd.c, and wanted to know what they could do | about it. It might be better to ask why those function arguments are | specified as "volatile" in the first place. | | What exactly does it mean to specify function arguments as volatile? | How can a stack location or a register be volatile, assuming the | computer is operating correctly and the compiler generates proper | code? The only reason I could come up with for making the arguments | volatile would be to prevent some brain-damaged compiler from | incorrectly optimizing references to them away. | | Can someone enlighten me? I personally think our compiler is right | for barking about this strange usage of the "volatile" specifier. | +--- The reason for the ANSI comittee to add the `volatile' specifier was nothing other than "suppressing optimizations", As quoted from K&R 2nd Ed. p. 211: The purpose of 'volatile' is to force an implementation to suppress optimization that could otherwise occur. This is to say that `volatile' doesn't necessarily mean that these are memory mapped registers, or any other thing for that matter. Optimizations may cause references (read/write/read-modify-write) to memory locations change their relative order or disappear completely (e.g. when the object is allocated a register), when this is undesired - the `volatile' specifier should be used. In the case of 'cmd.c', the reason for using `volatile' is that the function calls 'setjmp'. The use of 'setjmp' may cause a later 'longjmp' to resume into several locations *with all registers clobbered*. Not all compilers recognize the name 'setjmp' to treat it in a special way (i.e. not use registers around 'setjmp' calls). A stack location (in this case - a parameter) can be declared as volatile in order to supress optimizations. This should prevent the compiler from putting this parameter in a register. I'm afraid that a compiler which forbids the use of 'volatile' in this context is broken. BTW, Apollo has a very good optimizing compiler, and I don't want this sentence to be misconstrued. Note also that it merely gives warnings and not errors. Larry thought of such problems and enabled 'cmd.c' to withstand even broken compilers by using conditional compilation directives there. e.g. you can both define volatile, and use JMPCLOBBER, to mean that your 'setjmp' is POSIX compliant (doesn't save all GP-registers). This won't prevent the warnings though... I hope this clears up the matter a bit. | | thanks, | -steve | | | Steve Vinoski (508)256-0176 x5904 | Internet: vinoski@apollo.hp.com | | | HP Apollo Division, Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | -- Ariel Faigon National Semiconductor Corp. (NSTA Design Center) 6 Maskit St. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52-522272 arielf@taux01.nsc.com
tom@ssd.csd.harris.com (Tom Horsley) (05/22/91)
>>>>> Regarding VOLATILE in cmd.c; vinoski@apollo.HP.COM (Stephen Vinoski) adds: vinoski> Can someone enlighten me? I personally think our compiler is right vinoski> for barking about this strange usage of the "volatile" specifier. If you are doing setjmp/longjmp type processing within the routine and there is a chance the parameter might be kept in a register (as it very well might be, especially on a RISC machine where it got passed in one) then the volatile nonsense is required (actually, an additional requirement is that uses of the parameter must be reachable from the code following the setjmp). Personally, I wish that the ANSI C committee had mandated compiler support for setjmp(). If optimizing compilers were required to recognize setjmp() as a possible target of a non-local goto which might happen from "inside" any other function call, then they could get the data flow analysis and lifetime information correct, and volatile could be restricted to its proper usage - dealing with variables modified in signal handlers and shared memory. (Better yet, they could have added real exception handling to C and dropped setjmp/longjmp, but that's a real can of worms). If your compiler ignores volatile on function parameters, and there is any chance it will keep the parameter in a register, then your compiler may be broken (although it might be hard to contrive an example which would demonstrate it was broken). -- ====================================================================== domain: tahorsley@csd.harris.com USMail: Tom Horsley uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle Delray Beach, FL 33444 +==== Censorship is the only form of Obscenity ======================+ | (Wait, I forgot government tobacco subsidies...) | +====================================================================+