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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,148d39ae0d22411d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-02 04:00:13 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!chnws02.mediaone.net!chnws06.ne.mediaone.net!24.128.8.70!typhoon.ne.mediaone.net.POSTED!not-for-mail From: "Jeff Creem" Newsgroups: comp.lang.ada References: <3BB08F9C.BFB01047@raytheon.com> <3BB10D52.4D455DBA@raytheon.com> <3BB60733.4A80708A@avercom.net> <3BB64B13.81AFFB4D@acm.org> <5ee5b646.0109300510.71255128@posting.google.com> Subject: Re: Pragma Volatile X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Tue, 02 Oct 2001 10:59:23 GMT NNTP-Posting-Host: 24.61.92.65 X-Complaints-To: abuse@mediaone.net X-Trace: typhoon.ne.mediaone.net 1002020363 24.61.92.65 (Tue, 02 Oct 2001 06:59:23 EDT) NNTP-Posting-Date: Tue, 02 Oct 2001 06:59:23 EDT Organization: Road Runner Xref: archiver1.google.com comp.lang.ada:13614 Date: 2001-10-02T10:59:23+00:00 List-Id: "AG" wrote in message news:fVfu7.147$jc1.20018@news.xtra.co.nz... > > "Robert Dewar" wrote in message > news:5ee5b646.0109300510.71255128@posting.google.com... > > > > > I often find people making this kind of assumption, and > > in the case of reads I saw one awful bug caused by this: > > > > > > type R is array (natural range <>) of Boolean; > > pragma Pack (R); > > > > Register : R (1 .. 32); > > for Register'Address use ... > > > > ... > > > > B := Register (3); > > > > one compiler generated a word load, and extracted bit 3. > > another compiler generated a byte load, and extracted bit 3 from the > > byte. > > > > Both code sequences are perfectly valid, and just as > > efficient as one another. But the hardware had been > > build to require word loads, and byte loads were don't > > care and put the hardware into some obscure state. > > > > Isn't it true that a compiler that puts it's target machine into > some obscure state can't be called perfectly valid? After all, > it is the job of the compiler to either produce a valid code or > reject what isn't possible. Can you really call a code sequence > (generated by a compiler with no control by the programmer) > "perfectly valid" if it sends the target machine from here to > "some obscure state"? > > > But of course the real bug is in the implicit assumption > > in the code. > > Well, that may be a bug in the assumptions in the code, but > it also looks like a compiler bug in so far that it accepted and > (mis)implemented those assumptions. > > > No it is not a compiler bug for cases like this. It is not that the compiler puts the target into an obscure state. Cases like this arise when you have some specific hardware that you are address mapping to where that hardware does not allow certain addressing modes that ARE perfectly valid for the architecture of the processor. One could only say this is a compiler problem if the compiler was some strange compiler that was build to know about the specific hardware that you are interfacing to. (Like some magic gcc build built with) ./configure --target=power-pc-with-some-custom-hardware-at-address-0x404040- to0x505055-that-requires-longword-access-even-though-this-processor-is-byte- addressable (sorry for the 80 col violation but I was trying to get the point across). To put it another way, the code that the compiler generated would be fine if the address of the variable Register was in normal system RAM but falls apart when the address is mapped to some hardware that only allows longword (or some other specific) access.