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-09-30 06:10:03 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Pragma Volatile Date: 30 Sep 2001 06:10:03 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0109300510.71255128@posting.google.com> References: <3BB08F9C.BFB01047@raytheon.com> <3BB10D52.4D455DBA@raytheon.com> <3BB60733.4A80708A@avercom.net> <3BB64B13.81AFFB4D@acm.org> NNTP-Posting-Host: 205.232.38.14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1001855403 9274 127.0.0.1 (30 Sep 2001 13:10:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 30 Sep 2001 13:10:03 GMT Xref: archiver1.google.com comp.lang.ada:13548 Date: 2001-09-30T13:10:03+00:00 List-Id: Jeffrey Carter wrote in message news:<3BB64B13.81AFFB4D@acm.org>... > If a register is an Integer, I would generally do > > B : Integer; > for B'Address use Register_Location; > pragma Volatile (B); > ... > B := 0; > B := 1; > > But then, I don't have the C pointer fixation. Be very careful about assumptions here. Suppose that B is a 32-bit word, then there is nothing in the language that says that B := 0; has to generate a 32-bit store, it would be perfectly valid if the compiler generated a call to bcopy that moved four bytes independently (inefficient, but not incorrect). 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. The "fix" was to use a constrained base type (this was the only use of the type anyway), and then both compilers generated the 32-bit word load. But of course the real bug is in the implicit assumption in the code. Yes, it is very neat to use the address clause for memory mapped I/O devices, but it is definitely cheating in that it is making unwarranted assumptions about the exact code sequences generated. Technically such code is quite wrong, and should be replaced by machine code inserts. But that is heavy in practice. At the very least, document assumptions like this ferociously, and isolate them in special packages known to need looking at when porting. Robert Dewar Ada Core Technologies