Re: Modified proposals for Ada-Comment

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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.

> 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).

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)

> 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.

> !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".

> 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.

> 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?

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .