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.9 required=5.0 tests=BAYES_00 autolearn=ham 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 05:11:58 PST Message-ID: <3A6C2CDD.67FD79DC@baesystems.com> Date: Mon, 22 Jan 2001 12:51:41 +0000 From: Stuart Palin Organization: BAE SYSTEMS Avionics, Rochester X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Help with Atomic_Components and whole array assignment References: <94h55t$9a1$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: rc2966.rochstr.gmav.gecm.com X-Trace: 22 Jan 2001 12:45:40 GMT, rc2966.rochstr.gmav.gecm.com Path: supernews.google.com!sn-xit-02!sn-xit-04!supernews.com!europa.netcrusader.net!128.230.129.106!news.maxwell.syr.edu!newsfeed.icl.net!newsfeeds.belnet.be!news.belnet.be!btnet-peer1!btnet-feed3!btnet!newreader.ukcore.bt.net!pull.gecm.com!rc2966.rochstr.gmav.gecm.com Xref: supernews.google.com comp.lang.ada:4298 Date: 2001-01-22T12:51:41+00:00 List-Id: 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