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-30 07:54:34 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!newsxfer.eecs.umich.edu!news.bu.edu!inmet!not-for-mail From: Tucker Taft Newsgroups: comp.lang.ada Subject: Re: Help with Atomic_Components and whole array assignment Date: Tue, 30 Jan 2001 10:54:33 -0500 Organization: AverStar (formerly Intermetrics) Burlington, MA USA Message-ID: <3A76E3B9.BD806841@averstar.com> References: <94h55t$9a1$1@nnrp1.deja.com> <3A6C2CDD.67FD79DC@baesystems.com> <94hfaq$h3n$1@nnrp1.deja.com> <94hn5p$on4$1@nnrp1.deja.com> NNTP-Posting-Host: nebula.burl.averstar.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: inmet2.burl.averstar.com 980870073 21987 141.199.8.77 (30 Jan 2001 15:54:33 GMT) X-Complaints-To: usenet@inmet2.burl.averstar.com NNTP-Posting-Date: 30 Jan 2001 15:54:33 GMT X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:4706 Date: 2001-01-30T15:54:33+00:00 List-Id: Robert Dewar wrote: > > In article <94hfaq$h3n$1@nnrp1.deja.com>, > mark_lundquist@my-deja.com wrote: > > for I in A'range loop > > A (I) := 0; > > end loop; > > > > you'll get 1-byte writes, guaranteed. > > That is not correct. It seems correct if pragma atomic_components applies to A, since in that case, each component of A is an atomic object, and each update to an atomic object has a separate external effect, per C.6(20). > > It's hard to imagine a compiler wanting to generate anything > > but simply a 1-byte write for each element > > It's not hard at all. Converting this loop to a more efficient > form is a quite reasonable optimization (the Microsoft C > compiler does this for example, since it is a big win on > earlier implementations of the ia32 architecture. True, but such a transformation is not permitted if Atomic_Components applies. > > but if it did want to, RM C.6(20) would not allow it > > (violation of sharing properties of the other components). > > No, it is a perfectly legitimate optimization, and does not > violate the quoted section, which talks about generating extra > stores, not about combining store operations. I don't agree with Robert's reading of this. It seems very clear that you cannot combine multiple updates of separate atomic objects into a single write. One of the whole points of atomic is to make each write separate and indivisible. It was designed specifically to address issues relating to "active" memory, where breaking the write down into multiple writes, or combining multiple writes into a single write, would confuse the device. > ... > No, it is not swept under the carpet, it is clear from the > RM (as has been explained in many threads on the subject), that > if your application requires specific sequences of instructions > to be generated, then the ONLY legitimate way of doing this is > with machine language insertions. To think otherwise is a > recipe for mysterious and ill-documented implementation > dependencies (the GNU/Linux kernel suffered from these problems > early on). Well, I don't agree completely with these "many comp.lang.ada threads." Atomic is designed to provide additional control over what code the compiler generates. It doesn't specify exactly what instructions will be used, but it does require that each read/update be its own indivisible operation, however that is accomplished. In general, that means each read/update is a separate instruction. Which particular instruction is not specified, though of course in most cases it will be a load or a store. I don't agree with the advice of slipping into machine code to accomplish all of these kinds of things, if atomic can do the job. I would agree that with the original code, which used an aggregate assignment, there is no requirement to perform that as separate byte assignments. However, if the code is written as a sequence (or a loop) of separate assignments, and the objects are atomic, it is a bug (in my view) if the compiler combines these assignments into a single assignment. Similarly, reordering such assignments would be a bug, since it would change the external effect of the program in an impermissible way. > > --------------- > > Mark Lundquist > > Rational Software -- -Tucker Taft stt@avercom.net http://www.averstar.com/~stt/ Chief Technology Officer, AverCom, Inc. (A Titan Company) Burlington, MA USA (AverCom was formed 1/1/01 from the Commercial Division of AverStar) (http://www.averstar.com/services/ebusiness_applications.html)