Version 1.1 of acs/ac-00307.txt

Unformatted version of acs/ac-00307.txt version 1.1
Other versions for file acs/ac-00307.txt

!standard 13.5.1(13.4/2)          18-07-27 AC95-00307/00
!standard 13.5.3(2)
!standard 13.5.3(4)
!standard 13.5.3(5)
!class confirmation 18-07-27
!status received no action 18-07-27
!status received 17-10-11
!subject Non-default bit order
!summary
!appendix

From: Simon Wright
Sent: Sunday, July 1, 2018  3:34 PM

There's been discussion on c.l.a [He means comp.lang.ada - Editor] recently 
about AI12-0218, during which [1] there was a statement that Norman Cohen's 
paper [2] was implemented in Ada 2005 (AI95-00133).

AI95-00133 contains extensive references to the paper, but important things 
like 

   "The interpretation of component_clauses in the nondefault bit order 
   is based on machine scalars, which are chunks of storage that can be 
   natively loaded and stored by the machine. All of the 
   component_clauses at a given offset are considered to be part of the 
   same machine scalar, and the first_bit and last_bit are interpreted 
   as bit offsets within that machine scalar. This makes it possible to 
   write endian-independent record_representation_clauses." 

only appear in the AI, not the ALRM. 

And I think I'm right in saying that the size of the machine scalar starting 
at a given offset is determined by the largest last_bit of any of the 
components starting at that offset (so you'd better have a filler component
extending into the top half of a more-than-one-byte machine scalar if none 
of the actual components do). 

[1] https://groups.google.com/d/msg/comp.lang.ada/dZIHeAnlu9I/hW_BUPKJAAAJ
[2] http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf 

***************************************************************

From: Randy Brukardt
Sent: Sunday, July 1, 2018  6:14 PM

> AI95-00133 contains extensive references to the paper, but important 
> things like
> 
>    "The interpretation of component_clauses in the nondefault bit order 
>    is based on machine scalars, which are chunks of storage that can be 
>    natively loaded and stored by the machine. All of the component_clauses
>    at a given offset are considered to be part of the 
>    same machine scalar, and the first_bit and last_bit are interpreted 
>    as bit offsets within that machine scalar. This makes it possible to 
>    write endian-independent record_representation_clauses." 
> 
> only appear in the AI, not the ALRM. 

13.5.1(13.4/2) says exactly this (using "position" instead of "offset", since 
that's the actual name of the syntax in question), other than the fluff of 
"makes it possible":

for other component_clauses, all of the components having the same value of 
position are considered to be part of a single machine scalar, located at that
position; this machine scalar has a size which is the smallest machine scalar 
size larger than the largest last_bit for all component_clauses at that 
position; the first_bit and last_bit of each component_clause are then 
interpreted as bit offsets in this machine scalar. 

> And I think I'm right in saying that the size of the machine scalar 
> starting at a given offset is determined by the largest last_bit of 
> any of the components starting at that offset (so you'd better have a 
> filler component extending into the top half of a more-than-one-byte 
> machine scalar if none of the actual components do).

Again, the paragraph referenced above says exactly this.
 
> [1]
> https://groups.google.com/d/msg/comp.lang.ada/dZIHeAnlu9I/hW_BUPKJAAAJ
> [2] http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf

I'm confused. Your message has neither a question, a problem, nor any action 
that you'd like the ARG to take. It's just a random musing on the RM. What 
are you asking us to do?

***************************************************************

From: Simon Wright
Sent: Monday, July 2, 2018  2:27 AM

> I'm confused. Your message has neither a question, a problem, nor any action
> that you'd like the ARG to take. It's just a random musing on the RM. What
> are you asking us to do?

You've proved to me that I was wrong, so I apologise for that.

But, if I believe that the RM is wrong on some point, who - other than the ARG 
- am I supposed to raise the issue with?

***************************************************************

From: Randy Brukardt
Sent: Tuesday, July 3, 2018  12:30 AM

>You've proved to me that I was wrong, so I apologise for that.

No need to apologize, it happens to everyone periodically.

>But, if I believe that the RM is wrong on some point, who - other than 
>the ARG - am I supposed to raise the issue with?

It's perfectly fine to raise a question here. But try to actually raise a 
question, rather than just generally talking about the RM. I couldn't tell
if the claim about Machine_Scalars *was* the question or just some statement
tangential to the question. (That often happens in ARG discussions, as reading
things closely sometimes leads to more questions than answers.) I guess it was
the question in this case, based on your response.

If you had said something like "The AI gives the following discussion, but I 
can't find any rules like that in the RM", it would have been clearer what 
concern you had.

***************************************************************

Questions? Ask the ACAA Technical Agent