Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!uflorida!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Message-ID: <12151@mimsy.UUCP> Date: 26 Jun 88 15:29:29 GMT References: <11837@mimsy.UUCP> <3811@pasteur.Berkeley.Edu> <580@wsccs.UUCP> <5874@bloom-beacon.MIT.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 22 In article <5874@bloom-beacon.MIT.EDU> peter@athena.mit.edu (Peter J Desnoyers) writes: [shared memory:] >If p = cr_shr_mem( size) (I don't remember the name or all the args) >then the compiler must assume that memory from p to p+size is >volatile. However, if `size' is computed at run time, it is not >known to the compiler. (computing its range is equivalent to solving >the halting problem) Thus anything between p and the top of memory is >volatile. In fact, anything aliased with (p,maxmem) is volatile, and >deciding aliasing is not computable. Thus your whole data space is >volatile. Oops. In the most general case, this is true (although that depends on the details of cr_shr_mem). Hence I must back down a bit. I will ask, though, that if anything in [p..maxmem) could be volatile, how are you as a programmer going to deal with it? How do *you* know what the range of `size' will be? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris