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