Xref: utzoo comp.lang.c:9872 comp.arch:4583 Path: utzoo!yunexus!geac!daveb From: daveb@geac.UUCP (David Collier-Brown) Newsgroups: comp.lang.c,comp.arch Subject: Re: volatile (in comp.lang.c) Message-ID: <2686@geac.UUCP> Date: 2 May 88 19:57:12 GMT Article-I.D.: geac.2686 Posted: Mon May 2 15:57:12 1988 References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <9916@tekecs.TEK.COM> <2642@geac.UUCP> <2082@winchester.mips.COM> <2674@geac.UUCP> <2114@winchester.mips.COM> Reply-To: daveb@geac.UUCP (David Collier-Brown) Organization: The Geac History Department. Lines: 28 In article <2114@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: | As I thought I'd mentioned before, the most immediate cause of wanting | volatile has nothing to do with computer architecture in the sense of | 1), or OS theory/practice in the sense of 2), but the very simple, | practical reason, that in an open systems design, using a standard | bus, and buying off-the-shelf controllers, you will discover that | many such controllers, otherwise desirable, use memory as | a communication mechanism. Agreed. I was asking an architecture/theory question, in hopes of invalidating part of the problem. And it is a real problem: there is nothing improper or undesirable in using a portion of the address space for special purposes. Adding volatile or equivalent directives to languages is a perfectly reasonable tradeoff, expecially if the alternative is to break off a part of the address space for "i/o ports" as some microcomputer manufacturers do. Thats why I addressed it to the architects. I know why I'd need it as a programmer: (a). Or I can use (b) and write a very-machine-specific driver using lots of source-to-source transformations. I've written drivers in GMAP. Never again! --dave c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.