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: Modified proposals for Ada-Comment Date: Sat, 12 Jul 2014 18:45:28 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: Injection-Date: Sat, 12 Jul 2014 18:45:28 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="22933"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/sDJMCMPioQzAfNCS059rsD+6DO4Vo15M=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:sZCLOhqTv85BFZnyAxPbjWUGEnY= Xref: news.eternal-september.org comp.lang.ada:20890 Date: 2014-07-12T18:45:28+00:00 List-Id: 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