Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Message-ID: <11968@mimsy.UUCP> Date: 15 Jun 88 08:43:06 GMT References: <11837@mimsy.UUCP> <5080025@hpfcdc.HP.COM> <11936@mimsy.UUCP> <5766@bloom-beacon.MIT.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 57 In article <5766@bloom-beacon.MIT.EDU> peter@athena.mit.edu (Peter J Desnoyers) writes: >...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? Well, how did you tell me? (I am not sure you *did* tell me. I suspect you meant `buffer.length'. This is the kind of things you would like to describe [correctly] just once, then be able to refer to `that horrid little device over there'.) >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? If the compiler is to compute its own idea of volatility, it must understand all of this. Given that programmers already have enough trouble with `clr' instructions that use RMW cycles, making a compiler understand complicated DMA models would be quite difficult (but again, I claim, not impossible). I would be wary of a compiler that tries to do this (note phrasing :-) ), but I would still like to see it done. Incidentally, will 68000 (note three 0s) compilers studiously avoid `clr.l ea' for `ea' volatile? One would hope so, but putting that into a C language standard is clearly wrong. >One (unrelated) deficiency I see in |volatile| involves the generation >of spurious writes. Or reads. >In a perfect world, *p = x would generate one write and no read cycles, >at least if *p were volatile. ... 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. You are correct. Note that, for instance, volatile int *word = (int *)FOO; int tmp; tmp = *word; must generate two read cycles on an eight-bit peripheral attached to a 16-bit machine. (A common hardware hack to work around this problem, incidentally, is to wire [eg] the Z80 SIO chip to A1..An+1 instead of A0..An; Heurikon does this on the 68010 boards we have in McMob. All the device structures are full of pad bytes.) >I hope that the people who write cross-compilers keep this in mind >when they add ANSI features .... This is what X3J11 calls a `quality of implementation issue'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris