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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ffdd4d59cbfb4caf X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Ada 95 Numerics questions for the experts Date: 1997/09/09 Message-ID: X-Deja-AN: 271000101 References: Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-09-09T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >In article , 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