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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cbd507df3efa824b
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-01-22 06:30:07 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
From: mark_lundquist@my-deja.com
Newsgroups: comp.lang.ada
Subject: Re: Help with Atomic_Components and whole array assignment
Date: Mon, 22 Jan 2001 14:16:00 GMT
Organization: Deja.com
Message-ID: <94hfaq$h3n$1@nnrp1.deja.com>
References: <94h55t$9a1$1@nnrp1.deja.com> <3A6C2CDD.67FD79DC@baesystems.com>
NNTP-Posting-Host: 130.213.203.87
X-Article-Creation-Date: Mon Jan 22 14:16:00 2001 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)
X-Http-Proxy: 1.1 x59.deja.com:80 (Squid/1.1.22) for client 130.213.203.87
X-MyDeja-Info: XMYDJUIDmark_lundquist
Xref: supernews.google.com comp.lang.ada:4299
Date: 2001-01-22T14:16:00+00:00
List-Id: <comp.lang.ada>

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/