mash@mips.COM (John Mashey) (04/04/88)
(Cross-posted to unix.wizards: see comments at ned) In article <1988Mar30.110820.23882@light.uucp> bvs@light.UUCP (Bakul Shah) writes: >You must be able to tell a compiler that certain variables have side >effects *IF* you are using a highly optimizing compiler and you do one or >more of the following: (a good list) I've just been catching up with this. Let's try some data in place of theory. 1) I grepped both UMIPS kernels (BSD & V). Each has about 200 "volatile" declarations. Most of this was in device drivers, but there were a few other places. 2) Did we do this for fun? NO. We just couldn't globally optimize huge pieces of the kernel, until: a) Our compiler team put in volatile, and until b) We got volatile to act completely right. [nontrivial] We [the OS group] had just BARRELS of fun when we turned on -O before volatile was right. Every device driver, and various other things broke. This was 2 years ago, and I've mercifully forgotten many of the details, but I still remember this one (a structure not unusual in drivers): /* touch device until ready */ register struct device_stuff *p; int junk; while (p->status != READY) junk = p->control; /* or something like that */ The first time we tried that, the optimizer generated a single fetch of p->status [and never went back]. Then we declared p volatile , and at least the loop was there, but the compiler had noticed junk was never used, so it eliminated junk from any of its tables, and that wiped out the whole reference inside the loop....until the optimizer got fixed to be very, very careful to make exactly the right number of memory references for volatile variables [no more, no less]. 3) With volatile, it is relatively easy to import device drivers, usually by declaring all of the pointers to device structures to be (volatile *), and still be able to use a serious global optimizer. Otherwise, good luck. Hopefully, more drivers will start being written with volatile declarations. 4) It is easy enough to #define volatile away if you need to deal with a compiler that doesn't support it. I suppose there's some way to do this with a #pragma, volatile seems cleaner. 5) Perhaps UNIX kernel code is "an unusual case". I'd be curious if there is anyone out there, who: a) Globally optimizes their UNIX kernels, including drivers, but b) Uses something other than volatile. (how?) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
nevin1@ihlpf.ATT.COM (00704a-Liber) (04/05/88)
In article <1975@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >(Cross-posted to unix.wizards: see comments at ned) >In article <1988Mar30.110820.23882@light.uucp> bvs@light.UUCP (Bakul Shah) writes: > a) Our compiler team put in volatile, and until > b) We got volatile to act completely right. [nontrivial] In other words, you implemented 'volatile' to conform with the final definition in the ANSI standard?? What powers of prediction you have!! :-) What are you going to do if volatile doesn't act quite the way you defined it when your compiler team put in volatile?? -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
boyne@hplvly.HP.COM (Art Boyne) (04/05/88)
As regards the "volatile" discussion: There are many of us out here who use C in other than Un*x applications. For example, C is now the language of choice in this division of Hewlett-Packard for all firmware going into instruments. The existing C compiler doesn't support the keyword "volatile" but does support a compiler directive $AMNESIA ON$, which gives somewhat the same effect. This directive is used in a lot of sources that deal directly with the hardware; without it, we get the optimize-into-oblivion behavior described in the base note. For all of us in nitty-gritty land, lets hear it for volatile! Art Boyne, hplabs!hplvly!boyne
mash@mips.COM (John Mashey) (04/06/88)
In article <4268@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >In article <1975@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >> a) Our compiler team put in volatile, and until >> b) We got volatile to act completely right. [nontrivial] >In other words, you implemented 'volatile' to conform with the final >definition in the ANSI standard?? What powers of prediction you have!! :-) >What are you going to do if volatile doesn't act quite the way you defined >it when your compiler team put in volatile?? Change it, of course. However: 1) During standards efforts, if you're either involved with the efforts, or talk to people who are, it's not that hard to get a sense of: a) A feature is pretty well-understood, at least in intent, and you think that the syntax is going to be left alone, even if the descriptive material gets tuned. b) A feature is close, but there may well still be some tweaking. c) A proposed feature is causing outright battles. 2) In late 1985, it was pretty clear that volatile seemed in category a), or at worst, b), but certainly not c). It did not take precognitive abilities to be able to take a chance on implementing it. 3) The difficulties in getting it right were not in understanding what it meant, or worrying about how it was supposed to act, they were in implementing a well-understood intent inside an aggressive optimization system in a sensible way, when this is a mechanism not otherwise included, and when meeting volatile's intent required inhibiting more optimizations than obvious on first glance. There is of course a very simple way to do it if necessary: if anything says volatile, treat the entire C module as though all variables are volatile other than automatics. This would meet the letter of the spec. Actually, we also have a -volatile option that says "keep the optimization, but assume nonlocals are all volatile". This is very convenient when first importing some code. Then you go thru and put in volatile declarations, and delete the -volatile option. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086