comp.lang.ada
 help / color / mirror / Atom feed
* Modified proposals for Ada-Comment
@ 2014-07-12 18:45 Simon Clubley
  2014-07-12 21:00 ` Simon Wright
  2014-07-12 21:50 ` Niklas Holsti
  0 siblings, 2 replies; 7+ messages in thread
From: Simon Clubley @ 2014-07-12 18:45 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-07-17 21:15 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-12 18:45 Modified proposals for Ada-Comment Simon Clubley
2014-07-12 21:00 ` Simon Wright
2014-07-12 21:24   ` Simon Clubley
2014-07-12 21:50 ` Niklas Holsti
2014-07-12 22:19   ` Simon Clubley
2014-07-13  0:06     ` Simon Clubley
2014-07-17 21:15   ` Simon Clubley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox