Re: Caching & Annex C.6

[Robert Dewar <robert_dewar@my-deja.com>]

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.