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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Modified proposals for Ada-Comment Date: Sat, 12 Jul 2014 22:19:47 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Sat, 12 Jul 2014 22:19:47 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="46180df868476f30e9ca964f2af919c1"; logging-data="10206"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18P/LYx9c7nO+bRAo+56xKEnR+DMoWsUEA=" User-Agent: slrn/0.9.9p1 (Linux) Cancel-Lock: sha1:FKuAyoKwa+1mfBcQqKtnYuwjdrw= Xref: news.eternal-september.org comp.lang.ada:20895 Date: 2014-07-12T22:19:47+00:00 List-Id: On 2014-07-12, Niklas Holsti wrote: > On 14-07-12 21:45 , Simon Clubley wrote: >> Below are my modified proposals based on all your feedback. >> >> I've modified Issue 1 to make it clear it can also be used as a >> general subset capability and changed some existing wording to >> reflect that. > > Good. I would put even more emphasis on the general partial-aggregate > idea, and then describe the atomic bitfield update as one application > among others. > I don't want the core reason for the proposal to be lost, but I will have another look at the wording. >> Niklas, I have also added one of your examples to the proposal >> because it shows the more general uses very nicely. Is that ok, >> or would you like me to remove the example ? > > Quite ok. Feel free to include the array example too, I think it came > out neatly (the normal year vs leap year). > Thanks. I'll include the array example as well. > Randy mentioned some uses with SPARK, that would be very good to > include, given the emphasis of Ada 2012 on contracts and the recent > AdaCore work on proof tools. > > I have not yet used Ada 2012 contracts in my programming, but I believe > that partial aggregates would be quite useful in post-conditions, to > express that some "out" value is the same as some "in" value except for > changes to certain components: > > with Post => X = (X'old changing Colour => Black) > I have not done anything with SPARK or Ada 2012 yet, so I don't really want to start talking about things I don't really know anything about yet. Hopefully, Randy and company will examine this area as well. I will include a comment about this however. I will say however the potential uses for partial aggregates seems to be growing the more one looks at them. :-) >> Are there any further suggestions before I send them to Ada-Comment ? > > See below. > >> Issue 1: Partial Aggregate notation >> >> !topic Updating multiple record bitfields as an atomic operation > > The name of the "issue" and "!topic" are rather far apart. I would make > "partial aggregate notation" the "topic" and list atomic bitfield update > as one use, perhaps the motivating use. > Thanks. I'll have another look at that. >> !reference Ada 2012 RM{clause unsure} >> !from Simon Clubley 2014-07-12 >> !keywords bitfields records device registers atomic updating subset > > IMO "aggregate" should be included as a keyword, perhasps "partial > aggregate". > Ok. >> One suggested syntax would be: >> >> A := (A changing C => D, E => F); >> >> or >> >> A := (A updating C => D, E => F); > > We are probably bored stiff by the discussion of suitable keywords, but > I still want to say that I dislike the words "changing" and "updating" > because they suggest that the aggregate changes or updates some > variable. In my view, the partial aggregate, by itself, does not change > or update anything -- it constructs a composite value from component > values, just as any aggregate. The change or update comes when the value > is assigned to some variable. > I can see what you are saying, but an alternative word does not come to mind. Do you have any ideas ? >> where A is a record and C and E are record components. When this syntax >> discussion took place in comp.lang.ada one suggestion was "overriding" >> but I didn't like that because that keyword made it seem as if A was >> the one doing the overriding, not the later C and E references. >> >> For an Atomic record, the compiler would generate a Read-Modify-Write >> sequence and, as the operation would be on the record as a whole, >> C.6(15) would be guaranteed to apply and there would be a single >> read of the device register and a single write to the device register. >> >> For a normal record, the above would provide a general subset update >> capability. The following example was posted by Niklas Holsti in >> comp.lang.ada: > > You can remove the attribution, it would make the text smoother. > >> ----------------------------------------------------------------------------- >> Issue 2: Does Atomic apply to record components ? >> >> !topic Does Atomic on a record apply to it's components ? >> !reference Ada 2012 RMC.6(15) >> !from Simon Clubley 2014-07-12 >> !keywords Atomic update record components >> >> This submission was prompted by an issue identified recently in >> comp.lang.ada. On an ARM target, a 32-bit record, with multiple bitfields, >> was defined as Atomic. However, the generated code showed that when a >> bitfield, instead of the record as a whole, was referenced, GNAT used >> ldrb/strb (byte level access instructions) instead of ldr/str (32 bit >> access instructions) when the bitfield was within the first 8 bits >> of the record. > > Might you include in this question also whether increasing the size of > an atomic object using a 'Size clause means that the atomic access > should apply to all the bits included in 'Size, and not just to the bits > included in the declared components of the object? > I'll add some text about this. > As I remember, one feature of the original example and problem was that > the declared components in the record type all fit in one and the same > byte, and a 'Size clause was used to make the record use 32 bits, > meaning that most of the record type was "gap" components. > Thanks for the feedback, Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world