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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY 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: Robert Dewar Subject: Re: Caching & Annex C.6 Date: 1999/09/08 Message-ID: <7r5mb7$c4d$1@nnrp1.deja.com>#1/1 X-Deja-AN: 522499397 References: <7r4fao$h7o$1@nnrp1.deja.com> <7r4ted$e892@svlss.lmms.lmco.com> X-Http-Proxy: 1.0 x25.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Wed Sep 08 12:55:10 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-09-08T00:00:00+00:00 List-Id: In article <7r4ted$e892@svlss.lmms.lmco.com>, dkristol@see-my.sig wrote: > 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. That is not an optimization, it is a perfectly reasonable and valid translation of the Ada code. It is always very risky, and very implementation dependent, to assume you know exactly what machine instructions the compiler will generate for a given construct. If you need an exact load/store instruction, it is really much more appropriate to use an asm insertion to specify the exact instruction you need, rather than coax the compiler into generating the instruction you want. The latter is often highly non-portable, and can introduce insufficiently documented implementation dependencies in innocent looking code. Who would think that A := 0; could be a highly target dependent piece of code? One of the worst cases I saw of this was the following, someone had: Size : integer := 31; ... type x is array (0 .. Size) of Boolean; pragma Pack (x); for x use at bla bla; so far, so good, a typical memory mapped I/O specification. The code had things like Status := x (13); This worked fine on compiler V, but blew up on GNAT. Why? Because on the machine in question there were both word and byte loads and stores, neither being particularly preferred. Compiler V did a word load and a bit mask. GNAT did a byte load and a bit mask But the hardware had been built only to recognize word loads, and it blew up at the hardware level for a byte load, delivering random data to the bus (wonderful eh?) Needless to say this was hard to find. The kludge put in to fix this was to make the size constant, in which case GNAT now knows that the variable in question is exactly 32 bits long, and happens to do a word load, but this is really a very brittle way of "fixing" this. Much better would be to issue the exact instruction required. That being said, the suggestion of using integer is probably a good one, and this wlil likely minimize the possibility of unexpected code generation. << That particular bug took a while to track down >> Yes, indeed bugs like this in Ada code are devilish hard to find. And all too often people decide that their code cannot be at fault because it worked once upon a time. We have too often encountered situations where managers have been sold on the fiction that because their code is in Ada, it will be zero effort to port it to new platforms or new compilers :-( Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.