Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!agate!ig!uwmcsd1!bbn!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth From: firth@sei.cmu.edu (Robert Firth) Newsgroups: comp.lang.c Subject: Volatile is stupid Message-ID: <5800@aw.sei.cmu.edu> Date: 9 Jun 88 14:36:23 GMT References: <11837@mimsy.UUCP> <225800035@uxe.cso.uiuc.edu> Sender: netnews@sei.cmu.edu Reply-To: firth@bd.sei.cmu.edu.UUCP (Robert Firth) Organization: Carnegie-Mellon University, SEI, Pgh, Pa Lines: 32 I'm on Chris' side in this debate. The cue word "volatile" is unnecessary, stupid, and anyway insufficient for the job. The only way a programmer can know that an address is volatile is if he has read some document that says so: "the time-of-day register is 16#fffffeeb#, and when read will return the current time-of-day in millicatnaps since last Tuesday" Or, alternatively, he has built the hardware himself, stuffed it into the chassis, and scribbled a few notes in magic marker on the side. Either way, the programmer now has to do something special to all the programs (or all their header files) that reference that new hardware. Would it not be far simpler, and far safer, for the compiler to read a single "target memory definition file", or similar, that says 00000000..0003ffff is ROM 00040000..00ffffff is RAM fffffeeb is volatile and so on, and so on? If anyone changes the physical target, they edit the target memory definition file. The complier simply reads this file whenever it compiles a program, and does the right thing. If you are writing code for such a target, you have an environment variable or whatever that points to "/usr/targets/mc68000/TESTBENCH5.mdf", or some such. Not only does this work, it is amenable to decent verification, management, configuration control, and maintenance. "Volatile" is a hacker's answer.