Xref: utzoo comp.lang.c:10058 comp.arch:4759 Path: utzoo!mnetor!uunet!husc6!linus!philabs!micomvax!ray From: ray@micomvax.UUCP (Ray Dunn) Newsgroups: comp.lang.c,comp.arch Subject: Re: volatile (in comp.lang.c) Message-ID: <1030@micomvax.UUCP> Date: 5 May 88 14:16:52 GMT References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <9916@tekecs.TEK.COM> <2642@geac.UUCP> <2082@winchester.mips.COM> <2674@geac.UUCP> Reply-To: ray@micomvax.UUCP (Ray Dunn) Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada Lines: 34 In article <2674@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) asks: [On the necessity of "volatile"] > Specifically: > 1) what architectures currently use asynchronously-changing >memory locations for program notification of events? DEC Vax, >various CDC boxes, MIPS(tm),... The asking of this question is a clear example of the distorted view many people have, whose environment is restricted to DEC, SUN, CDC, IBM etc *standard* machines. This is not meant as a flame, only as an observation. The answer to the question is "as many architectures as there are proprietary designs of micro-processor based equipment which use asynchronously changing memory locations, including *all*, for example, which use memory mapped I/O. As I said in an earlier posting (on reflection not very succinctly), a compiler for a particular [micro-processor] CPU can make *no* assumptions about the architecture that the compiled code is running on, other than [the architecture of the microprocessor itself]. Writing a compiler for a 68000 is a different exercise than writing one for a VAX, which is a fully defined environment. So it's not reasonable to make these controls [e.g. "volatile"] a compiler specific thing. They *have* to be part of the language. -- Ray Dunn. | UUCP: ..!{philabs, mnetor}!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090