Re: Help with Atomic_Components and whole array assignment

[Stuart Palin <stuart.palin@baesystems.com>]

r_c_chapman@my-deja.com wrote:

Hi Rod!

> Having a slight confusion over the use of array aggregate assignments
> with Atomic_Components.
> 
> We have a device which _has_ to be accessed use byte-wide load
> and store instructions only (it's an autostore NOVRAM...), so we
> have an array of bytes declared, thus:
> 
>   type Byte is range 0 .. 255;
>   for Byte'Size use 8;
>   for Byte'Alignment use 1;
>   type Index is range 0 .. 4; -- for argument's sake!
>   type Byte_Array is array (Index) of Byte;
>   pragma Volatile (Byte_Array);
>   pragma Atomic_Components (Byte_Array);
> 
>   A : Byte_Array;
>   for A'Address use ...
> 
> 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.

  The "portability" argument is that since this access mechanism is
specific to your
  architecture it should be re-examined if you change the hardware
anyway, so using
  MACHINE_CODE conveniently highlights the areas of software you should
look at.

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.


--
Stuart Palin
Principal Software Engineer
BAE SYSTEMS Avionics Ltd, Rochester
G-NET 791 3364    mailto:stuart.palin@baesystems.com