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 12:16:04 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newshub2.rdc1.sfba.home.com!news.home.com!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed.earthlink.net!uunet!lax.uu.net!sac.uu.net!usenet.rational.com!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada Subject: Re: Help with Atomic_Components and whole array assignment Date: Mon, 22 Jan 2001 11:52:49 -0800 Organization: Rational Software Message-ID: <94i3qq$qr5$1@usenet.rational.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: ext-3038.rational.com X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: supernews.google.com comp.lang.ada:4331 Date: 2001-01-22T11:52:49-08:00 List-Id: Robert Dewar wrote in message news:94hn5p$on4$1@nnrp1.deja.com... > 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'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. Ah, I didn't mean for the loop... but unfortunately, it's the loop that's relevant :-(. What I just meant for the assignment statement itself. That is, you'd expect a byte-addressable machine to generate a byte-wide access for an assignment of a byte-wide type, not, for instance, a 32-bit read, mask, logical or, then 32-bit write -- and I was saying that although you can't otherwise assume that behavior, the atomicity rules would enforce it (which you shot down in flames below :-). But anyway, I missed the forest for the trees at that point -- of course the compiler *can* say, "oh, he's initializing this array... I know a better way". Now then... if you pull out the byte write into its own procedure, then as long as you know the compiler doesn't do any automatic inlining before it tries to optimize the loop(and it doesn't do global optimization)... Hah! I just said that to get to you... and it worked, didn't it? Eh?... :-) :-) Yeah, I know, if I have to say "as long as you know the compiler X" then it's wrong. Reminds me of the old Benny Hill episode... "Never ASSUME! It makes an ASS out of U and ME!" > > > 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. Phooey... you're right. > > > > Personally; this seems to be a recurrent embedded systems > > > proble (that > > > is either agonized over or [in]conveniently swept under the > > > carpet). > [note, someone else said this -- it was just part of the post I was replying to...] > 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). > > > > It would be nice if it were addressed at the next language > > > revision. > > [...] > I suppose we could add > > pragma Full_Memory_Access (type); > > but at most we could only have implementation advice that this > meant that every read or write must be done with a single > instruction that affects those bits and nothing else (this > basically would be a stronger and weaker condition than atomic, > stronger, because it forbids, e.g., combing writes, or reading > more than is needed, weaker, because at the bus level, there is > no requirement for invidisibility. Well, yeah, I think that is the idea! :-) > > But we could only make this implementation advice, since there > is really no clear way at the semantic level to talk about > generated instructions Don't volatility/atomicity kind of suffer from this in general? And why couldn't you go stronger than implementation advice, and say the implementation is required to do X on platforms where X is meaningful? > (consider for example that such a rule > is completely meaningless when you are running in a JVM > environment). Sorry, I don't really know anything about the JVM so this example doesn't mean anything to me... So if you feel like elaborating, I'm interested, otherwise no need... Best, -- mark