Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!peter From: peter@athena.mit.edu (Peter J Desnoyers) Newsgroups: comp.lang.c Subject: Re: volatile Message-ID: <5590@bloom-beacon.MIT.EDU> Date: 1 Jun 88 21:45:13 GMT References: <20345@pyramid.pyramid.com> <502@wsccs.UUCP> <51431@sun.uucp> <227@proxftl.UUCP> <11709@mimsy.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: peter@athena.mit.edu (Peter J Desnoyers) Organization: Massachusetts Institute of Technology Lines: 53 In article <11709@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >In the limit, the compiler may simply assume that all variables are >volatile and aliased; it will then act much like the C compilers we >have been using on Unix systems. It may produce suboptimal code, >but it will produce correct code, and it does not need a `volatile' >keyword. C compilers on most Unix systems do not assume that all variables are volatile, and they certainly do not assume that all memory is volatile. In the first case, the program results would be at best completely undefined, and in the second case code generation would be impossible, as there would be no guarantee that the processor would ever get to see it before it was modified. > >This does not mean that `volatile' is bad. It merely means that >I feel that a compiler that, given something like the following, >prints a warning that `rkaddr' should be declared `volatile' (since >the proposed C has the keyword) is superiour to one that does not. > > struct rkdevice *rkaddr = (struct rkdevice *)0777440; > >(Clearly this requires knowledge of the machine internals, and >may have to be enabled by switches, e.g. It remains useful.) >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) >Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris Most compilers know nothing of a machine's internals. They run on a vax or some other machine, and generate code for a microprocessor. Not a system, a microprocessor. Which physical memory locations are going to be volatile may not be known when the program is written, and certainly not when the compiler is written. Besides, the proprietary design of a board is no business of the compiler company, anyway. The situation is similar for MSDOS machines. The compiler does not know whether a piece of code will be executed with EMS, EEMS, company X's I/O board in slot Y, or all of the above. The programmer does. These and a thousand other factors determine what areas of the memory map are volatile. Others may be used to communicate with TSR's, and will never be known to the compiler writers no matter how hard they look. /* flame on */ Don't be a Unix chauvinist. If everyone wrote Unix applications on Unix machines, nothing would get done. Remember that somewhere down the line, someone is using those machines to develope code that gets burned into a ROM, put in a box, and sold to a customer. /* flame off */ Peter Desnoyers peter@athena.mit.edu