Re: Ada 95 Numerics questions for the experts

[bobduff@world.std.com (Robert A Duff)]

In article <mheaney-ya023680000809972047000001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>In article <EG7FIq.Ivw@world.std.com>, bobduff@world.std.com (Robert A
>Duff) wrote:
>
>>>I assumed that by specifying
>>>the component size to be 3, that that meant the component size should be 3. 
>>>How naive of me!
>>
>>Well, it should, 
>
>I'm confused by this answer.  What does you mean when you say that the
>component size "should" be 3?

You tell me.  You're the one who used the word "should".  You said
"... should be 3", and I agreed, yes it should.  ;-)

>...Is it 3, or isn't it?  Assuming conformance
>to Annex C, can a compiler legally compile the declaration (that doesn't
>have a pragma Pack), and _not_ give the array a component size of 3?

Yes.  But there's a case where it's not clear what it *means* for the
component size to be 3:

>>but what should 'Component_Size be for an array of
>>3-bit components, where the implementation puts 10 of them in each word,
>>and leaves a gap of 2-bits at the end of each word?  (I'm assuming
>>32-bit words, here.)

So, what's *your* answer to the above 2-bit gap example?  Imagine that
there's no rep clauses, but the implementation just happens to choose
the above representation.  Now what does T'Component_Size return?

The RM's answer is that these components are 3 bits.  They're certainly
not 4 bits.  And we don't have any way of imagining that they're 3.2
bits (that is 32 bits per word, divided by 10 components per word),
since Component_Size is an integer number.

Sometimes I feel like chapter 13 is like one of those showers where a
single knob controls both the temperature and the water flow, so you can
have a small amount of cold water, or a lot of hot water, but you can't
have a trickle of hot water.  I would prefer to have orthogonal
controls.

>>If there's a "gap" of 1 bit between each 3-bit component, then I don't
>>think that should be called a "gap" at all -- we should call that
>>situation "4-bit components".
>
>Again, I am confused by your answer.  What does it mean to say that "I
>don't think" it should be called a gap, or we "should" call the situtation
>4-bit components?  Doesn't the RM define the meaning of the term "gap"? 
>What was the intent of the RM, if it doesn't define gap?

The RM tries to define "gap" (in 13.1(7), with lots of AARM verbiage
explaining what we thought we meant), but like lots of things in chap
13, the term "gap" is at the wrong semantic level, so definitions are
sometimes unclear or meaningless.  The "intent" is as I stated above --
if there are 8 components per 32-bit word, that's considered 4-bit
components, not 3-bit components with 1-bit gaps in between each one.

RM83 didn't define "gap" at all, but the common usage made it much
harder to nail down the meaning of rep clauses, since the compiler could
pretend to insert bogus gaps all over the place.  The intent of 13.1(7)
was, in part, to prevent that.

>Yes or no: According to the RM, is dense, no-gaps-between-the-components
>packing _implied_ by the specification of a Component_Size clause?  Or is
>pragma Pack always required as part a declaration?

The intent is that 'Component_Size = 3 might mean full packing, or might
mean a single 2-bit gap at the end of each word, and pragma Pack forces
the former (if supported at all).  But Robert has pointed out that
13.3(73) also seems to allow *more* than a 2-bit gap per word, which was
obviously not intended.  (I say "obviously", because it would make "for
T'Component_Size use 3;" completely useless.  See also 13.3(73.a) for a
hint as to what was meant.)

Note that if an implementation tried to take Robert's literal reading,
and say that 3-bits causes a 1-bit gap between each component, then it
would have to mask out that bit on loads, as required by 13.1(7) -- at
least if you think 13.1(7) means anything at all.  But no implementation
would do *that*, so I think you're safe assuming the intent will hold.

I really think you have to read chap 13 in a "friendly" way, since it's
not (and can't be) quite as precise as the rest of the RM.  I mean,
consider a strict reading wrt:

    type Color is (Red, Yellow, Green);
    for Color use (Red => 100, Yellow => 205, Green => 320);

Suppose the implementation says, "Yes, we represent Red as 100, but
we're free to represent integer numbers however we like, and we choose
(in this case) to represent 100 as the bit pattern consisting of all
zeros.  Likewise, we represent 205 as ...0001, and 320 as ...0010."
Nothing in the RM forbids that, when read strictly, but it would totally
negate the point of the rep clause.  The ACVC is quite correct to forbid
the above interpretation, even though it takes a "nudge, nudge, you know
what we mean" sort of reading of chap 13.

>Robert says that both a pragma Pack and a component size clause are
>required to be given in order to guarantee that component size.  Is this
>the intent of the RM?  Or is he reading the RM too literally?  (I should
>rephrase that last question: Is there an error in the RM, such that its
>statements about also requiring a pragma Pack, are ambiguous?)

- Bob