From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,251afb8f1c322bf0 X-Google-Attributes: gid103376,public From: dkristol@see-my.sig (David Kristola) Subject: Re: Caching & Annex C.6 Date: 1999/09/08 Message-ID: <7r4ted$e892@svlss.lmms.lmco.com>#1/1 X-Deja-AN: 522416790 Distribution: world References: <7r4fao$h7o$1@nnrp1.deja.com> Organization: heaps of stacks Reply-To: dkristol@see-my.sig Newsgroups: comp.lang.ada Date: 1999-09-08T00:00:00+00:00 List-Id: In article 1@nnrp1.deja.com, Robert Dewar () writes: >In article <7r1l93$9lq4@svlss.lmms.lmco.com>, > dkristol@see-my.sig wrote: >> I work with real-time embedded systems, and we use pragma >> Volatile to mark variables that represent (and are located >> on) memory mapped registers. The data must be written to >> the memory mapped register when that code executes. >> Likewise, many of those registers return values set by >> hardware, so reads can't come from the cache. > >But usually the ensurance of non-caching of these addresses >will be done at the hardware level, it is not something the >compiler worries about. The compiler's responsibility is >simply to issue loads and stores, someone else must make >sure that the loads and stores work as planned (for example >on the MIPS one bit of the address space is used to indicate >cachability). There are machines with different loads and >stores to control caching, but not many! True. Those memory mapped register variables are also placed at the correct location using the uncached address in the representation specification. And after being burned by one compiler, i started using appropriately sized integers for the register overlay, and calling unchecked conversion to convert the data to the register's record structure. This eliminated the compiler's optimization which inadvertently read and wrote bytes on either side of the register. Those bytes happened to be parts of other registers, and the hardware did not handle byte access properly. That particular bug took a while to track down. --djk, keeper of arcane lore & trivial fluff Home: David95037 at aol dot com Spam: goto.hades@welovespam.com