Re: Ada 95 Numerics questions for the experts

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Michael asks

<<a)  X'model_epsilon
b)  X'model_small
c)  something else
d)  it depends (if so how?)
>>


the only possible answer is d). You need to figure out exactly what
test you need, and then program it. Perhaps an exact equality is
appropriate, perhaps using one of the measures related to rounding
discrepancies is appropriate, perhaps some entirely different test
is appropriate (for example if you are doing Simpon's rule integration,
you need to be quite careful about the test for convergence, and a test
like model_epsilon will likely be much TOO tight, and will miss the
convergence point -- I used to have great fun giving this out as an
assignment early on, students sure burned up a lot of CPU time missing
the convergence point :-)

If the equality is to do with comparing observations from the physical 
world, then you need to find out how precise these observations are.
For example, suppose we are searching a data base of people for a match,
and one of the items is the height represented in floating point. A test
for equal heights using model_epsilon or anything similar would be 
ludicrous. Instead we need to get some idea of how accurate the 
data is, and perhaps 0.5 might be a reasonable tolerance for comparing
heights in inches.

On the other hand, to repeat an example I have given before, if you are
computing square roots using Newton Raphson iteration on a machine with
a reasonable floating-point model, iteration to identify may be appropriate.

There is no easy answer to your question, you are simply fooling yourself
if you think you can replace analysis by a simple rule of the type
suggested by (a) or (b) above.

Re: Ada 95 Numerics questions for the experts

[David C. Hoos, Sr.]

Just a couple of points, viz.:

  1.  The DEC Ada compiler for VAXen allowed biased rep clauses, as well.
       It's gratifying that gnat chose to implement this also.

  2.  The problem with your packed array example, however, is that what you
       are asking the compiler to do is to force array elements which are
smaller than
       one byte to straddle byte boundaries.  No compiler likes to do this,
as far as I
       know. (Record components straddling byte boundaries, are another
matter, and they
       are handled quite nicely without any ugly source code).
       Simply using pragma Pack instead of a "for 'size use 24" clause will
result in your
       8-element x 3-bit array occupying 32 bits, which is not bad at all.
       Undoubtedly, the extra code required to mask and shift the varying
amounts as
       a function of the array index would substantially exceed the one
byte of array
       size saved.  Besides, even if the compiler did give you your 24-bit
array, it would
       probably skip to the next 32-bit boundary for the next object in
memory, anyway.
       Even gnat will not give you a 24-bit array for this case (at least
the WinNT version 3.09).
       
David C. Hoos, Sr.       

Jeff Creem <jeffrey.m.creem@lmco.com> wrote in article
<jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com>...
> In article <dewar.872630607@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:
> 
> >Jeff says
> >
> Even something like
> 
> type My_Type is range 0 .. 7;
> for My_Type'size use 3;
> type My_Array is array(1 .. 8) of M
> for My_Array'size use 24;
> 
> 
> Is not allowed because the element size of My_Arary is less than 8 it
> rounds to 8 for each element.  This can be a real pain at times. While
> I basically agree with the rational in the LRM for the minimum level of 
> support I think that if a compiler supports the systems programming annex
that
> rep specs like mine above should be required (of course I would think
> that since it is something I wanted....I'm not biased :)
> 
> The cool GNAT rep spec example that robert gave would also be nice but
> probably not required. If a compiler does not support the rep specs
> like in roberts example the code to work around it is pretty minor, if
> it does not support component sizes less than 8 and you really need
> them to interface to hardware, the code gets ugly very quickly and
> often starts to look like ugly C code.
> 
> 
> In any case GNAT handles everything I've ever wanted in a rep spec.. Too
> bad there is not a supported vxWorks port..
> 
> Jeff
> 

Re: Ada 95 Numerics questions for the experts

[Jeff Creem]

In article <01bcb2f2$b512f700$928871a5@dhoos>, "David C. Hoos, Sr."
<david.c.hoos.sr@ada95.com> wrote:

>Just a couple of points, viz.:
>
>  1.  The DEC Ada compiler for VAXen allowed biased rep clauses, as well.
>       It's gratifying that gnat chose to implement this also.
>
>  2.  The problem with your packed array example, however, is that what you
>       are asking the compiler to do is to force array elements which are
>smaller than
>       one byte to straddle byte boundaries.  No compiler likes to do this,
>as far as I
>       know. (Record components straddling byte boundaries, are another
>matter, and they



But VADS, Apex and GNAT all do handle this (essentially)


>       are handled quite nicely without any ugly source code).
>       Simply using pragma Pack instead of a "for 'size use 24" clause will
>result in your
>       8-element x 3-bit array occupying 32 bits, which is not bad at all.
>       Undoubtedly, the extra code required to mask and shift the varying
>amounts as

Nope. The AdaMajic front end (Green hills in this case) rounds the
components to 8 bits even in the precense of a pragma pack
you get a 64 Byte array.

>       a function of the array index would substantially exceed the one
>byte of array
>       size saved.  Besides, even if the compiler did give you your 24-bit
>array, it would
>       probably skip to the next 32-bit boundary for the next object in
>memory, anyway.


Actually in the real code that the example came from, the array was an
 element of a record with another field. The total length of the record
was then 32 bits.


>       Even gnat will not give you a 24-bit array for this case (at least
>the WinNT version 3.09).
>       

It gives you a 32 bit array (which Is what I would expect) but does allow
you to stick it in a record with another 8 bits and have a structure which
is a total of 32 bits long.. Again very nice

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

<<Nope. The AdaMajic front end (Green hills in this case) rounds the
components to 8 bits even in the precense of a pragma pack
you get a 64 Byte array.>>

SOunds like a bug to me, since these compilers say they support
annex C, this means that the implementation advice in chapter 13 (13.2(9))

    9  For a packed array type, if the component subtype's Size is less
       than or equal to the word size, and Component_Size is not
       specified for the type, Component_Size should be less than or
       equal to the Size of the component subtype, rounded up to the
       nearest factor of the word size.

which of course becomes a requirement if you claim annex C support.

Reading this paragraph, we see that it is OK to round up to 4-bits,
but certainly not 8-bits.

As I noted before, GNAT does not round up at all, and packs tightly at
3 bits, letting components spill over byte and word boundaries. This
is not required by para 9, but is of course consistent with it ("less
than or equal").

Re: Ada 95 Numerics questions for the experts

[Jeff Creem]

In article <dewar.872745692@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>SOunds like a bug to me, since these compilers say they support
>annex C, this means that the implementation advice in chapter 13 (13.2(9))
>
>    9  For a packed array type, if the component subtype's Size is less
>       than or equal to the word size, and Component_Size is not
>       specified for the type, Component_Size should be less than or
>       equal to the Size of the component subtype, rounded up to the
>       nearest factor of the word size.
>
>which of course becomes a requirement if you claim annex C support.
>
>Reading this paragraph, we see that it is OK to round up to 4-bits,
>but certainly not 8-bits.



It was a matter of me misreading the error message. It says that
the specified compontent size 3 is not a factor of 8, rounding to a factor
... Which of read as rouding to a multiple of 8 (multiple/factor boy I
better run back to 2nd grade). 

Even still I think my original (modified by Robert) comment holds that while
the AdaMajic front end meets the requirements of the LRM it does the
minimum needed to meet those requirements in most areas (no support for
Ada 83 only attributes and pragmas) and limited support (although correct)
for rep specs.


Jeff

Re: Ada 95 Numerics questions for the experts

[Tucker Taft]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:

: <<Nope. The AdaMajic front end (Green hills in this case) rounds the
: components to 8 bits even in the precense of a pragma pack
: you get a 64 Byte array.>>

: SOunds like a bug to me, since these compilers say they support
: annex C, this means that the implementation advice in chapter 13 (13.2(9))
: ...

Sounds like a misconception to me.  The compiler supports packing to
the bit level.  It would be helpful if the actual source code that
illustrated the problem were posted, because we have never had
a bug report relating to an inability to pack.

As far as packing to an array of 3-bits per element versus 4-bits per
element, we have generally chosen to follow the recommendations of the
RM.  Going beyond the RM is not always in the customer's interest,
as they may have to move to another Ada compiler at some point, and
one of the goals of standardization is portability between implementations.

For example, we used to support very long source lines, though the actual
limit was a bit hard to define.  We now support exactly 200 as the maximum
length of a line (which is the length guaranteed by the RM), because 
supporting something like 256 or some other number chosen by us did not 
seem to be doing the customer a great favor.

Of course, if a customer was willing to pay extra to get tighter packing, 
perhaps in the presence of some special pragma Jam_Packed(xxx), we would be
happy to accommodate them (I think this general "disclaimer" applies
to ACT as well ;-).  However, as mentioned above, we have currently 
chosen to follow the RM recommendations as closely as possible for
the "standard" pragma Pack, and if you find that we don't, please 
file a bug report.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

P.S. By the way, on our 24-bit-per-storage-unit target, we pack arrays
to element sizes of 1, 2, 3, 4, 6, 8, and 12.  I remember someone
once arguing for a word size of 72 bits on the grounds that it had
a lot of factors ;-).

Re: Ada 95 Numerics questions for the experts

[Robert A Duff]

In article <EFoIvv.JtA.0.-s@inmet.camb.inmet.com>,
Tucker Taft <stt@houdini.camb.inmet.com> wrote:
>...I remember someone
>once arguing for a word size of 72 bits on the grounds that it had
>a lot of factors ;-).

With a storage element of 9 bits, I presume?  I mean the word size
pretty much has to be a power-of-2 times the storage element size,
right?

- Bob

Re: Ada 95 Numerics questions for the experts

[Tom Moran]

> someone once arguing for a word size of 72 bits on the grounds that it had
> a lot of factors
60 has just as many factors and was in fact the word size, as I recall,
on the CDC 6600 series.

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Tuck said

<<As far as packing to an array of 3-bits per element versus 4-bits per
element, we have generally chosen to follow the recommendations of the
RM.  Going beyond the RM is not always in the customer's interest,
as they may have to move to another Ada compiler at some point, and
one of the goals of standardization is portability between implementations.>>

Tuck says "follow the recomendations" here where he means "follow the
minimal requirements". There is a big difference.

In this particular, case the RM recommendation is that the level of packing
(for 3-bit components) result in a component size less than or equal to 4.

GNAT chooses 3. Since 3 is (last time I looked) less than or equal to 4, 
GNAT is not "going beyond" the RM here, it is following the implementation
advice of the RM (and this IA is in fact a requirement, given that
GNAT supports Annex C).

If Tuck had wasnted the RM to recommend that the component size should
be exactly 4, he should have written this (although I am not sure
others would have agreed it was a good choice, we have seem quite a
bit of code that demands close packaing of 3-bit components (both
VADS and Alsys at least, supported this feature).

Yes, as Tuck says, if your primary concern is that code written for your
compiler be easy to move to other compilers, then you implement the
minimal lower bound. But if, as in the case of GNAT, your primary goal
is to be inclusive, and correctly process code from other existing
compilers providing a wide range of functionality that is permitted by
the RM, but not required, or recommended against, then you implement
the maximum.

Note that GNAT whereever possible follows the advice in the RM even if
it causes portability troubles. A common example is the following

  type arr8 is array (1..8) of boolean;
  for arr8'size use 8;

The RM permits the size clause to cause implicit packing, but recommends
against it. VADS at least permitted this implicit packing (even though
there was an AI that recommended against it).

Consequently in GNAT, we reject the above, and require an explicit pragma
Pack. The workdaround for existing code here is easy, and the code is
arguably clearer with the pragma there in any case.

However, if you have code that depends on close packed 3 bit components,
you are completely up the creak if your compiler does not support it!

Re: Ada 95 Numerics questions for the experts

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Tuck said
>
>> Going beyond the RM is not always in the customer's interest,
>> as they may have to move to another Ada compiler at some point, and
>> one of the goals of standardization is portability between implementations.
>
>Tuck says "follow the recomendations" here where he means "follow the
>minimal requirements". There is a big difference.
...
>Yes, as Tuck says, if your primary concern is that code written for your
>compiler be easy to move to other compilers, then you implement the
>minimal lower bound. But if, as in the case of GNAT, your primary goal
>is to be inclusive, and correctly process code from other existing
>compilers providing a wide range of functionality that is permitted by
>the RM, but not required, or recommended against, then you implement
>the maximum.

Does GNAT have an option to warn about the use of non-portable constructs
such as the ones discussed in this thread?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Ada 95 Numerics questions for the experts

[Robert A Duff]

In article <dewar.873149493@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Note that GNAT whereever possible follows the advice in the RM even if
>it causes portability troubles. A common example is the following
>
>  type arr8 is array (1..8) of boolean;
>  for arr8'size use 8;
>
>The RM permits the size clause to cause implicit packing, but recommends
>against it.

It would be pretty hard for the RM to do anything more than "recommend"
here.  After all, the compiler is allowed to use 1-bit components all
the time (even if that's not a good idea), or to use 1-bit components if
the program is compiled on a the first Tuesday of the month (an even
worse idea!), or to follow the phase of the moon.  Given that, how could
the RM do more than "recommend"?

>... VADS at least permitted this implicit packing (even though
>there was an AI that recommended against it).

One can't blame VADS *too* much.  The AI appeared after VADS had
implemented some particular mechanism.  Ada 95 merely codified the AI
into the RM.

>Consequently in GNAT, we reject the above, and require an explicit pragma
>Pack.

Or, presumably, a "for arr8'Component_Size use 1;".  Good.

>... The workdaround for existing code here is easy, and the code is
>arguably clearer with the pragma there in any case.
>
>However, if you have code that depends on close packed 3 bit components,
>you are completely up the creak if your compiler does not support it!

And, also unfortunately, the RM doesn't nail down what 3-bit components
would mean.  On a 32-bit machine, it might mean 10 3-bit components per
word, with a 2-bit wastage in each word, or it might mean 3-bit
components, crossing word boundaries, with no wastage.  Sigh.

I don't feel *too* bad about that -- other languages with similar
features (eg packed arrays in Pascal) are even less specific.

- Bob

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Matthew says (responding to me)

<<>Note that GNAT whereever possible follows the advice in the RM even if
>it causes portability troubles. A common example is the following
>
>  type arr8 is array (1..8) of boolean;
>  for arr8'size use 8;
>
>The RM permits the size clause to cause implicit packing, but recommends
>against it. VADS at least permitted this implicit packing (even though
>there was an AI that recommended against it).
>
>Consequently in GNAT, we reject the above, and require an explicit pragma
>Pack. The workdaround for existing code here is easy, and the code is
>arguably clearer with the pragma there in any case.

I'm confused: why wouldn't you recommend that T'Component_Size be used,
instead of pragma Pack?

for arr8'Component_Size use 1;

instead of

pragma Pack (arr8);>>


shrug! for a compiler that implements annex C, these are guaranteed to
have identical effect, and in fact one cannot imagine a compiler not
supporting pragma Pack for this case. 

Note that specifying a component_size other than 1,2,4,8 etc. is NOT
guaranteed to give a no gaps imlementation even if the implementatoin
advice IS followed (see RM 13.3(73)).

But back to your example, since both declarations have EXACTLY the same
status:

a) if the chapter 13 IA is not followed (annex C not supported), then neither
declaration is guaranteed to give a no-gaps implementation.

b) if the chapter 13 IA is followed (annex C supported), then both declarations
are guaranteed to give a no-gaps implementation.

So there is really no need to have a preference for one over the other, and
I suspect that your preference is based on some misunderstanding of the
RM requirements.

If you go to non-standard sizes like 3,5,7, then in GNAT, both
declarations are still equivalent, up to a component size of 32.
But as we have heard, that is not necessarily the case with other
Ada 95 compilers.

To be specific, consider the example:

  type x is range 0 .. 7;

  type r is array (1 .. 10) of x;

1) pragma Pack (r);
2) for r'Component_Size use 3;

If you use BOTH these declarations, then they must be either obeyed with
close packing or rejected as illegal.

If you use 1) without 2), then an implementation supporting annex C must
give you a component size of 3 or 4 (assuming typical implementations).
The Intermetrics compiler gives 4, GNAT will give 3.

(the Intermetrics compiler should reject the combination of both 1) and 2)
together, since it does not support this combination)

If you use 2) without 1), then even an implementation supporting annex C
is completely free to do whatever it wants -- that's probably an oversight,
and I would guess that typical implementations will behave the same as if
1) is used without 2). Anyway in this case, GNAT will still pack tightly
to 3 bits. I do not know what the Intermetrics compiler will do in this 
case, since, as I say, the RM places no bounds on what an implementation
can do if given a component size without a pack pragma and it is not
a factor or a multiple of the word size. Here is the para in question

   73  An implementation should support specified Component_Sizes that
       are factors and multiples of the word size.  For such Component_
       Sizes, the array should contain no gaps between components.  For
       other Component_Sizes (if supported), the array should contain no
       gaps between components when packing is also specified; the
       implementation should forbid this combination in cases where it
       cannot support a no-gaps representation.

So all in all, pragma Pack is stronger than using Component_Size in a
compiler implementing annex C, and in a compiler not implementing annex
C, there are no requirements at all, except to reject 1) and 2) together
if you don't do them right, so perhaps actually the most reliable thing
is to always use BOTH declarations, that way they must be obeyed or
rejected and if we are talking about 1,2,4 etc, we know exactly what
obeyed means.

So to be specific:

   type r is array (1 .. 8) of Boolean;
   pragma Pack (r);
   for r'component_size use 1;

must either be obeyed with close packing, or rejected, even bvy a compiler
that does not say anything about supporting annex C.

I find this all quite odd, but that is what the RM, quite clearly, says!!!!

Re: Ada 95 Numerics questions for the experts

[Matthew Heaney]

In article <dewar.873504953@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>      For
>       other Component_Sizes (if supported), the array should contain no
>       gaps between components when packing is also specified; the
>       implementation should forbid this combination in cases where it
>       cannot support a no-gaps representation.

That about explains it.  I wasn't aware that packing and component_size
clauses were intended to be used together.  I assumed that by specifying
the component size to be 3, that that meant the component size should be 3. 
How naive of me!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Ada 95 Numerics questions for the experts

[Robert A Duff]

In article <mheaney-ya023680000509972116500001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>That about explains it.  I wasn't aware that packing and component_size
>clauses were intended to be used together.  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, 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.)

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".

- Bob

Re: Ada 95 Numerics questions for the experts

[Matthew Heaney]

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?  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?

>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.)
>
>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?

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?

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?)

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Ada 95 Numerics questions for the experts

[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

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Bob said

<<It depends what you're trying to do.  If you really care about the exact
size of the components (e.g. because you're interfacing to external
hardware or software), then use a Component_Size clause.  If you just
want to squeeze the thing down to a reasonably small size, because you
know that will be more efficient, then pragma Pack is more appropriate.

In the case mentioned here, where the components will fit in 1 bit, it
won't actually make any difference, that is:

>for arr8'Component_Size use 1;
>
>instead of
>
>pragma Pack (arr8);

both of the above will result in arr8'Component_Size = 1, and arr8'Size
= 8.>>


This is surpringly wrong. Bob, you must go read the RM, it was written
by this clever fellow Bob Duff, and will tell you the TRUTH :-) :-)


First, in the absence of implementation of annex C, neither declaration
will guarantee close packing.

In the presence of close packing, it is true that both will guarantee
this, but given the two declarations

    pragma Pack (array_type);
    for array_type'component_size use array_component_type'size;

it is never the case that, as suggested by Bob Duff's quote, that the
second form is somehow more exact than the first. I find this odd, but
then I did not write the RM!

There are two issues to consider

1. Is annex C implemented? If not, then either of these declarations on their
   own may have no effect. 

2. If annex C is implemented, then

   is the component size or size of the component a factor or multiple of
   the word size?

   if yes, then either of these two declarations will do the job

   if NOT, then pragma Pack is stronger because it will do no worse than
   go up to the next factor (e.g. 3 moved to 4), but a component size
   clause can be completely ignored, since there is no requirement to
   implement component clauses in this case (technically what you do
   is to accept the component claiuse, but then implement allowed gaps),

Note that using BOTH clauses together is useful, since in this case, the RM
guarantees that a compiler that accepts the clauses, even if it does not
implment Annex C, MUSt do the right thing.

Odd eh?

Re: Ada 95 Numerics questions for the experts

[Robert A Duff]

I said:

><<It depends what you're trying to do.  If you really care about the exact
>size of the components (e.g. because you're interfacing to external
>hardware or software), then use a Component_Size clause.  If you just
>want to squeeze the thing down to a reasonably small size, because you
>know that will be more efficient, then pragma Pack is more appropriate.

In article <dewar.873592294@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

>This is surpringly wrong. Bob, you must go read the RM, it was written
>by this clever fellow Bob Duff, and will tell you the TRUTH :-) :-)

Sorry, I should have clarified that my advice was stylistic.  It doesn't
matter what the RM says -- stylistically, Pack means "minimize space,
more or less", and "for T'Component_Size use N" means, "I want exactly
N-bit components".  Surely Pack had that feeling in Ada 83, and the
addition of requirements in Ada 95 was merely a response to
implementations that failed to do *anything* to minimize space, so we
had to specify *how much* (as a minimum) space has to be minimized.

Besides, the allegedly "clever" Bob Duff who wrote that portion of the
RM is no more.  I no longer spend 24-hours a day thinking about language
issues.  ;-)

>First, in the absence of implementation of annex C, neither declaration
>will guarantee close packing.

Yeah, yeah, I know that all bets are off if the impl doesn't support
Annex C.

- Bob

Re: Ada 95 Numerics questions for the experts

[Matthew Heaney]

In article <EG7FA3.EKK@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:


>Sorry, I should have clarified that my advice was stylistic.  It doesn't
>matter what the RM says -- stylistically, Pack means "minimize space,
>more or less", and "for T'Component_Size use N" means, "I want exactly
>N-bit components".  Surely Pack had that feeling in Ada 83, and the
>addition of requirements in Ada 95 was merely a response to
>implementations that failed to do *anything* to minimize space, so we
>had to specify *how much* (as a minimum) space has to be minimized.

Assume conformance to Annex C, and I compile this declaration:

type T is range 0 .. 7;
type A is array (Integer range 1 .. 10) of T;
for A'Component_Size use 3;

Yes or no: if the implementation doesn't support a component size of 3, can
it still compile this declaration, giving A some other component size?

From what Robert Dewar said, it seems that, if we interpret the RM
literally, one must also include a pragma Pack, in order to get the
compiler to reject the declaration (if it doesn't support a component size
of 3).

I ask because there might be a bug in the RM, and that the intentation of
the RM is that the compiler reject the declaration above, in spite of the
fact that there is no pragma Pack, if it doesn't support that component
size.

So, Bob Duff, writer of the RM, answer yes or no: is pragma Pack required
in the example above, in order to guarantee that the component size really
is 3?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Ada 95 Numerics questions for the experts

[Robert A Duff]

In article <mheaney-ya023680000809972030110001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>So, Bob Duff, writer of the RM, answer yes or no: is pragma Pack required
>in the example above, in order to guarantee that the component size really
>is 3?

First define what you mean by "the component size really is 3", and then
I'll answer the question.  ;-)

(I'm not sure how I got promoted from RM co-author to RM author.)

By the way, note that the PDP-10 had hardware support for the 10 3-bit
components per 33-bit word, with a 2-bit gap at the end of each word,
and it would make no sense to do tighter packing on that machine.
(Well, it was actually a 36-bit word, but you know what I mean --
something like 5 7-bit components per 36-bit word, with a 1-bit gap,
which was the only sensible representation of Ada 83's String type.
Note that String has a pragma Pack.)

- Bob

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Tuck said

<<As far as packing to an array of 3-bits per element versus 4-bits per
element, we have generally chosen to follow the recommendations of the
RM.  Going beyond the RM is not always in the customer's interest,
as they may have to move to another Ada compiler at some point, and
one of the goals of standardization is portability between implementations.
>>

This is certainly a legitimate goal, but very different from the goal of
GNAT which is to be as inclusive as possible, so that it is as easy as
possible to move code *from* other compilers *to* GNAT.

We have found many customers who need close packing at arbitrary bit
sizes (or GNAT would not support it!)

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

David said (with nasty lines > 80 chars :-)

  2.  The problem with your packed array example, however, is that what you
       are asking the compiler to do is to force array elements which are
smaller than
       one byte to straddle byte boundaries.  No compiler likes to do this,
as far as I
       know. (Record components straddling byte boundaries, are another
matter, and they
       are handled quite nicely without any ugly source code).
       Simply using pragma Pack instead of a "for 'size use 24" clause will
result in your
       8-element x 3-bit array occupying 32 bits, which is not bad at all.
       Undoubtedly, the extra code required to mask and shift the varying
amounts as
       a function of the array index would substantially exceed the one
byte of array
       size saved.  Besides, even if the compiler did give you your 24-bit
array, it would
       probably skip to the next 32-bit boundary for the next object in
memory, anyway.
       Even gnat will not give you a 24-bit array for this case (at least
the WinNT version 3.09).



GNAT most certainly allows elements to straddle storage boundaries, and
will tightly pack any component size up to 32 bits.

The following is quite acceptable to GNAT:

package j is
  type x is range 1 .. 5;
  for x'size use 3;
  type r is array (0 .. 7) of x;
  pragma Pack (r);
  for r'size use 24;
  type m is array (1 .. 10) of r;
  pragma pack (m);
  for m'size use 240;
end j;

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Jeff says

<<GNATs ability to handle rep specs like your example is actually very cool
and the first compiler I know of that handles this type of case. The AdaMajic
front end is even more limited than not allowing your cool example.
Even something like

type My_Type is range 0 .. 7;
for My_Type'size use 3;
type My_Array is array(1 .. 8) of M
for My_Array'size use 24;


Is not allowed because the element size of My_Arary is less than 8 it
rounds to 8 for each element.  This can be a real pain at times. While
I basically agree with the rational in the LRM for the minimum level of
support I think that if a compiler supports the systems programming annex that
rep specs like mine above should be required (of course I would think
that since it is something I wanted....I'm not biased :)>>



Actually DEC Ada 83 handles biased types (the reason we implemented it in
GNAT was for DEC Ada 83 conmpatibility).


Also, your example is wrong thinking. You cannot (more accurately should
not be able to) use a size clause to affect the internal layout of an
array. Obviously the default layout for MY_array would be expected to
use one byte/element.,

If you want the packed representation, you must use pragma Pack, and then
indeed GNAT will happily pack the 8 elements into 24 bits.

The relevant RM quote is RM 13.3(53)

53   A Size clause on a composite subtype should not affect the internal
layout of components.


GNAT follows this implementation advice. If it were not followed, you can
get surprising expensive change of representation conversions happening
behind your back as a result of type derivation.

It is a continuing problem that, despite similar advice in Ada 83 AI's,
some Ada 83 compilers, notably VADS, violate this implementation advice,
so oftem we have to tell people to add a pragma Pack.

Re: Ada 95 Numerics questions for the experts

[Robert Dewar]

Jeff said

<<do. Since most of my prior experience has been with
VADS I never took note of that LRM reference however I still am a fan of
the size clause being applied after the pragma pack since if the pack does
not pack the elements as tightly as you'd like the size clause gives the
compiler an oportunity to complain that it can not fit the structure into
the number of bits your have requested.>>

Indeed, the confirming size clause is definitely appropriate. In fact consider
the example that inspired the thread:

  type x is range 0 .. 7;
  for x'size use 3;

  type r is array (1 .. 8) of x;
  pragma Pack (r);
  for r'size use 24;

The size clause says here, I *really* want tight packing, the RM allowed
expansion to 4 bits is not acceptable.

Now your code will be accpted by GNAT that is doing what you want, but
rejected by a compiler taking advantage of the RM's permissiveness here.

Of course this rejection may mean you have a problem on your hands, but
at least you know right away at compile time.

Re: Ada 95 Numerics questions for the experts

[Robert A Duff]

In article <jeffrey.m.creem-2708970802350001@ljd155.sanders.lockheed.com>,
Jeff Creem <jeffrey.m.creem@lmco.com> wrote:
>...The AdaMajic
>front end is even more limited than not allowing your cool example.
>Even something like
>
>type My_Type is range 0 .. 7;
>for My_Type'size use 3;
>type My_Array is array(1 .. 8) of M
>for My_Array'size use 24;
>
>Is not allowed because the element size of My_Arary is less than 8 it
>rounds to 8 for each element.

Any compiler that supports the above is broken (assuming a typical
32-bit machine).  I doubt if either GNAT or AdaMagic support it (can you
show the exact code you compiled on both compilers?).  A Size clause
does not control the internal layout of components.  Instead, you should use
"for My_Array'Component_Size use 3;" or "for My_Array'Component_Size use 4;"
or "pragma Pack(My_Array);".  Assuming a typical 32-bit machine, the
compiler must support 4-bit components (if it claims to support the SP
annex), and it *might* support 3-bit components -- this applies to both
Pack and Component_Size.  Component_Size is for when you care about the
exact size, whereas Pack is for when you want the compiler to minimize
space, but don't particularly care about (in this case) 3 vs. 4.

For a record with 8 3-bit components, on the other hand, the compiler
must support 3-bit packing.  Perhaps we should have required the same
for arrays that fit in a word.

Note that "for My_Type'size use 3;" is redundant -- My_Type'Size = 3 by
default.  You can put in the Size clause just to get a warm comfy
feeling that the compiler agrees with you on the size, if you like, but
it's not strictly necessary.

- Bob