Re: Help with Atomic_Components and whole array assignment

[mark_lundquist@my-deja.com]

In article <3A6C2CDD.67FD79DC@baesystems.com>,
  Stuart Palin <stuart.palin@baesystems.com> wrote:
> r_c_chapman@my-deja.com wrote:
>
> > [...]
> > all fine so far.  When we initialise this array, thus:
> >
> >   A := Byte_Array'(others => 0);
> >
> > compiler A generates 1 Word-sized store and 1 Byte-sized store.
> > (Target is PowerPC by the way.)
> > Compiler B (or should that be "G" :-) ) generates similar code on
IA32.
> >
> > Can anyone confirm this is indeed acceptable behaviour?
>
> Yes it is (from a language specification point of view) - a deja news
> search should throw up several discussions on the topic.
>
> The pragma volatile has been observed, because the operation is on
> object (not some locally cached version of it).
>
> The pragma atomic_components has been observed because each component
is
> indivisibly updated (within the bounds of an architecture assumption
> that the word write is not divisible).
>
> --# hide;
> Ultimate answer seems to be package MACHINE_CODE is the way to go if
the
> there is a specific way memory has to be accessed.

Or, just access the array one element at a time (no whole array or
slices).  If instead of

   A := Byte_Array'(others => 0);

you write

   for I in A'range loop
      A (I) := 0;
   end loop;

you'll get 1-byte writes, guaranteed.  It's hard to imagine a compiler
wanting to generate anything but simply a 1-byte write for each
element, but if it did want to, RM C.6(20) would not allow it
(violation of sharing properties of the other components).

> [...]
> Personally; this seems to be a recurrent embedded systems problem
(that
> is either
> agonized over or [in]conveniently swept under the carpet).  It would
be
> nice if it were addressed at the next language revision.

I agree, it would be very nice not to have to work around this.

Here's another embedded systems issue I'd like to see taken up: I'd
like to see bit order fixed, i.e. the ability to write endian-
independent record representation clauses.

---------------
Mark Lundquist
Rational Software



Sent via Deja.com
http://www.deja.com/