Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!peter From: peter@athena.mit.edu (Peter J Desnoyers) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Message-ID: <5766@bloom-beacon.MIT.EDU> Date: 14 Jun 88 19:05:48 GMT References: <11837@mimsy.UUCP> <5080025@hpfcdc.HP.COM> <11936@mimsy.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: peter@athena.mit.edu (Peter J Desnoyers) Organization: Massachusetts Institute of Technology Lines: 28 ... [Ross Cunniff argues that you could defeat a compiler 'manual' of volatile locations; Chris Torek argues that extending the manual would take care of the problem.] I think that there are things out there not dreamt of in Chris' philosphy. For instance, if I have an i/o chip that does complicated dma, how do you tell the compiler that when I add `buffer' to a certain queue, all locations starting at &buffer + sizeof(buffer.header), for &buffer.length {bytes/words/bits} are volatile until the buffer is taken from another queue? Will your mechanism work for another, even more complicated dma scheme? What if you can change the dma model by writing to a device register? One (unrelated) deficiency I see in |volatile| involves the generation of spurious writes. In a perfect world, *p = x would generate one write and no read cycles, at least if *p were volatile. (Read and write do screwy things with some dumb i/o devices.) I don't have a copy of the draft standard, but I would assume that this is the sort of thing that ANSI would never dream of specifying, as it might prevent a correct implementation on some architecture. I hope that the people who write cross-compilers keep this in mind when they add ANSI features, but from what I've seen of current cross-compilers, I don't have much hope that they will concentrate on making their products useful. (1/2 :-) Peter Desnoyers peter@athena.mit.edu