Re: Modified proposals for Ada-Comment

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2014-07-12, Niklas Holsti <niklas.holsti@tidorum.invalid> 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