Re: Green Hiils AdaMULTI 2000 -> Motorola Coldfire

[Robert Dewar <robert_dewar@my-deja.com>]

In article <3A5EF610.66C153D2@earthlink.net>,
  "Marc A. Criley" <mcquad2@earthlink.net> wrote:
>  For
> example:
>
>    type Counts is range 0..128;
>    for Counts'size use 32;
>
>    subtype Subcounts is Counts range 1..128;
>
> then
>    Counts'Size is 32
>    Subcounts'Size is 8
>
> This is caused by a gap in the Ada 95 definition regarding
> "sizes", which I think Robert Dewar alluded to in an earlier
> message.

This is NOT a "gap" in Ada 95. The above behavior is
specifically required by the Ada 95 RM, and any Ada 95
compiler that supports annex C that does NOT give this behavior
is (rather seriously) non-conforming. The relevant RM section
is 13.3

   55  The Size (if not specified) of a static discrete or
       fixed point subtype should be the number of bits needed
       to represent each value belonging to the subtype using
       an unbiased representation, leaving space for a sign bit
       only if the subtype contains negative values.  If such a
       subtype is a first subtype, then an implementation
       should support a specified Size for it that reflects
       this representation.

Clearly this requires a size of 8 for the above subtype.
Remember that recommendations of this kind become requirements
if annex C is supported.

> I don't recall the LRM reference that results in this
> behavior, but it's defininely there and one is barred from
> making the behavior otherwise.

Yes, right, but that's not a "gap", it is well defined
requirement. If anything it is Ada 83 that has the gap in
leaving this unspecified (i.e. Ada 83 is equivalent to Ada 95
without the advice and without Annex C). The trouble is that
the designers simply made a choice which was pragmatically
wrong, since it did not match what almost all commonly used
Ada 83 compilers did (I have been told, but do not know first
hand that the Intermetrics compiler for IBM mainframes made
the choice in the Ada 95 style, which if true, probably
accounts for the mistake).

It is an unfortunate mistake, since it is the source of a
significant amount of porting problems.

Making the situation worse, the Size attribute in Ada 95 is
subtype specific. You might think that this means that you
can specify it for subtypes, but no such luck (this was an
intended feature, but (unwisely in my view) got removed rather
late on). So compounding the design mistake here is that no
only is the default size wrong in the above example, but you
cannot override this incorrect size.

In GNAT, we have added the Value_Size attribute, which can
be specified for subtypes, so you could do:

  for Subcounts'Value_Size use 8;

and then the value of Subcounts'Size would be 8 (yes, it would
be neater if we could say:

  for Subcounts'Size use 8;

but there is a rule in the RM prohibiting this extension. They
are definitely out to make this as annoying as possible :-) :-)

> I recall, though, ACT informing me that _objects_ of either
> of those Counts or Subcounts types would occupy the requested
> 32 bits (and they do in GNAT)--I believe there was some
> implementation freedom regarding that aspect.

Yes, there is implementation freedom here, and the decision
in GNAT is to always inherit what we call the Object_Size
from the parent type, since we found that was a very common
assumption in legacy code. Furthermore, Object_Size is
introduced as an attribute in GNAT so that you can control
the object size (on a subtype by subtype basis).

So as long as you are using GNAT, there are relatively easy
ways of dealing with this. And if putting in a bunch of
declarations is still too much, we have the:

   pragma Use_VADS_Size;

configuration pragma, which duplicates (as closely as possible,
the documentation is not entirely complete), the effect of both
the size attribute and the size attribute definition clause in
VADS Ada 83.

> In the few places where we had to deal with this situation,
> we simply replaced the subtype with the parent type at, and
> only at, the place where the difference in size had an
> effect.  Everywhere else we continued to use the subtype to
> ensure proper type constraining.

Of course finding these places can be tricky. A particularly
nasty case is the following:

  type x is record
     A : Natural;
     B : Natural;
  end record;

  for x use record
    A at 0 range 0 .. Natural'Size - 1;
    B at 0 range Natural'Size .. 2 * Natural'Size - 1;
  end record;

  for x'size use 2 * Natural'Size;

The horrible thing about this declaration is that in almost
all Ada 83 compilers it nicely lays out (assume 32 bit integer)
the record as two 32-bit words, with a length of 64.

In Ada 95, it silently lays out the record with the fields
occupying 31 bits, the second field overlaps word boundaries,
and the record has a size of 62 bits, likely leading to
entirely horrible inefficiencies.

Indeed a suggestion we have filed is to always generate a
warning for Natural'Size on the grounds that it is almost
certainly a nasty surprise of this type :-(


Sent via Deja.com
http://www.deja.com/