Modified proposals for Ada-Comment

Modified proposals for Ada-Comment

[Simon Clubley]

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.

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 ?

Issue 2 has been restructured based on Randy's feedback.

Are there any further suggestions before I send them to Ada-Comment ?

BTW, Randy: I see the Ada 2012 RM states one issue per email submission
to Ada-Comment so I will send them to you as two different emails unless
you want them combining up into one email.

Thanks,

Simon.

-----------------------------------------------------------------------------
Issue 1: Partial Aggregate notation

!topic		Updating multiple record bitfields as an atomic operation
!reference	Ada 2012 RM{clause unsure}
!from		Simon Clubley 2014-07-12
!keywords	bitfields records device registers atomic updating subset

[Note: the focus below is on the atomic updating of device registers.
However, the proposed syntax would be a good way to give Ada a general
subset updating capability. It was suggested in comp.lang.ada that this
syntax be supported for the updating of record components in general
(not only atomic records with bitfields) and with array aggregates.
I agree with both of these suggestions.]

Ada can model the bitfields in a device register as a record type
containing those bitfields and can map an instance of that record
type to the address of that device register.

However, sometimes there is a requirement to be able to update a
subset of those bitfields as an atomic operation while preserving
the contents of the other bitfields in the record.

In Ada, the only way to do this (apart from C style bitmasks on a
integer variable) is to read the device register into a temporary
instance of the record type, modify the temporary variable and
write the temporary variable back to the device register.

This, to put it mildly, is ugly.

A far better approach would be a new partial aggregate syntax in which
the list of record components to be modified would be listed along with
their new values.

One suggested syntax would be:

	A := (A changing C => D, E => F);

or

	A := (A updating C => D, E => F);

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:

|For example, given a record type Rec with many components, one of which
|is Colour, a variable R of type Rec, and the need to call procedure Foo
|twice, once using R with its own Colour, and once with R but using the
|Black colour, we could do:
|
|   Foo (R);
|   Foo ((R changing Colour => Black));

I do think we need a new keyword because we are talking about adding
a subset update capability to Ada and that new usage should stand out
in any code.

Thanks,

Simon.

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

This broke the hardware requirement that the register this record was
been used to access must be accessed in units of 32 bits.

Scenario:

Consider a 32 bit record marked as Atomic. This record consists of
multiple bitfields and is used to model the bitfields in a 32 bit
memory mapped device register. The hardware requires the device
register to be read from and written to in units of 32 bits.

Now consider the following statement:

	Device_Register.bitfield := 1;

When this specific bitfield in the record, say 4 bits wide, is written
to, does the Atomic attribute on the record require the record to
be accessed in units of 32 bits or is the compiler permitted to
generate code to access, say, 8 bits of the record only ?

C.6(15) states:

	For an atomic object (including an atomic component) all reads and
	updates of the object as a whole are indivisible.

There are conflicting opinions about the above rule in comp.lang.ada.
The words "as a whole" in C.6(15) were used to justify the position that
access to this single bitfield is not required to be in units of the
record size which on the surface seemed reasonable.

However, other opinions are that C.6(15) does apply when accessing this
single bitfield.

Which opinion is correct ?

I would like C.6(15) to apply, but I am more interested in obtaining a
firm decision so other options can be considered if it doesn't.

Possible solutions:

If C.6(15) applies when accessing a single bitfield in an Atomic record,
then this is clearly a GNAT bug and needs handling as such.

If C.6(15) is deemed not to apply to a single bitfield, then we need a
mechanism to indicate, in the program source code, that the compiler is
not allowed to use segmented access to reference a bitfield in an Atomic
record.

If the partial aggregate proposal is approved, then this could be the
mechanism. If it is not approved, then a pragma/aspect along the lines
of "No_Segmented_Access" could be the mechanism to enforce this.

I do believe a mechanism is required in Ada itself however. The special
requirements of the register should be declared in the source code, for
the compiler (and maintainers) to see, so that it can be guaranteed to
be honoured when the code is compiled.

Thank you,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Modified proposals for Ada-Comment

[Simon Wright]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

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

Likewise when the bitfield was in the MS 8 bits. I haven't tried with
bitfields of length greater than 1.

> C.6(15) states:
>
> 	For an atomic object (including an atomic component) all reads and
> 	updates of the object as a whole are indivisible.
>
> There are conflicting opinions about the above rule in comp.lang.ada.
> The words "as a whole" in C.6(15) were used to justify the position
> that access to this single bitfield is not required to be in units of
> the record size which on the surface seemed reasonable.

I think the problem is with the phrase "as a whole". If it means that
partial access need not be indivisible it probably needs to spell it out
better, because that is completely at odds with what I would expect of
"atomic".

> However, other opinions are that C.6(15) does apply when accessing
> this single bitfield.

I think that the "other opinions" are that "as a whole" is a mistake, so
that C.6(15) should say

   For an atomic object (including an atomic component) all reads and
   updates of the object are indivisible.


Aside from these niggles, a useful pair of proposals.

Re: Modified proposals for Ada-Comment

[Simon Clubley]

On 2014-07-12, Simon Wright <simon@pushface.org> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> 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.
>
> Likewise when the bitfield was in the MS 8 bits. I haven't tried with
> bitfields of length greater than 1.
>

Oops. :-) I missed that bit. (And I already pointed it out in response
to your other posting and had made a mental note to edit it at that
time. :-))

>> C.6(15) states:
>>
>> 	For an atomic object (including an atomic component) all reads and
>> 	updates of the object as a whole are indivisible.
>>
>> There are conflicting opinions about the above rule in comp.lang.ada.
>> The words "as a whole" in C.6(15) were used to justify the position
>> that access to this single bitfield is not required to be in units of
>> the record size which on the surface seemed reasonable.
>
> I think the problem is with the phrase "as a whole". If it means that
> partial access need not be indivisible it probably needs to spell it out
> better, because that is completely at odds with what I would expect of
> "atomic".
>

Oh, I agree. It will be interesting to see what Randy and company have
to say.

>> However, other opinions are that C.6(15) does apply when accessing
>> this single bitfield.
>
> I think that the "other opinions" are that "as a whole" is a mistake, so
> that C.6(15) should say
>
>    For an atomic object (including an atomic component) all reads and
>    updates of the object are indivisible.
>
>
> Aside from these niggles, a useful pair of proposals.

Thanks. I'll wait another day or so for further comments and then
submit the proposals.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Modified proposals for Ada-Comment

[Niklas Holsti]

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

Re: Modified proposals for Ada-Comment

[Simon Clubley]

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

Re: Modified proposals for Ada-Comment

[Simon Clubley]

On 2014-07-12, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> 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.
>

I've had a bit more of a think about this and I think I'm going to turn
it into something that's a more general partial aggregate proposal with
the original atomic bitfield record proposal as the primary example along
with the other uses you have identified.

However, someone else will have to fill in the detailed SPARK/Ada 2012
specific examples you have suggested if Randy wants to see them but
I will include a general reference to them.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Modified proposals for Ada-Comment

[Simon Clubley]

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

The response (from Tucker Taft) I got to your 'Size question was this:

My original question as submitted:

||    As a related question, when C.6(15) does apply, does it also apply to
||    all the bits included by 'Size when 'Size has been used to increase
||    the size of the atomic object (say from 5 bits to 32 bits) ?
||

The response:

|
|The definition of 'Size on an elementary object is that it refers to the
|number of bits normally read/written, as specified in 13.1(7/2):
|
|  "The representation of an object consists of a certain number of bits
|  (the size of the object). For an object of an elementary type, these are
|  the bits that are normally read or updated by the machine code when
|  loading, storing, or operating-on the value of the object...."
|
|For a non-atomic composite object, extra bits might not be loaded/stored,
|again quoting from that same paragraph:
|
|  "... For a composite object, padding bits might not be read or updated in
|  any given composite operation, depending on the implementation."
|
|For an atomic composite object, although it is not stated explicitly, the
|implication is that the 'Size of an atomic object determines the number of
|bits read/written indivisibly (e.g. see C.6(11/4)).

On a related matter, the responses to the C.6(15) question about if
Atomic on a record applies to it's components, are in the general
direction of no it doesn't.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world