Re: Tick SIZE questions

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <1994Oct17.102945.1@condor>, gomberga@logica.co.uk (Greg Gomberg)
writes: 

|> Q1. What exactly does the LRM mean about the difference between 'SIZE as
|> applied to an object and to a (sub)type - bits allocated vs "minimum number of
|> bits..." LRM13.7.2(5).

This paragraph of the RM has been superceded by Ada Rapporteur Group
interpretation AI-00536, approved by WG9 in June 1990.  The main points
of AI-00536 are: 

   1. For an object X, X'Size is the number of bits allocated to hold X.
      This may or may not include padding bits, since the distinction
      between padding bits and bits that are part of the value is not
      well defined.

   2. Given a length clause

          for T'Size use N;

      (where T is a base type or first named subtype), the attribute
      S'Size, where S is a subtype T (possibly T itself), must yield the
      value N. Then, given the declaration

          X: S;

      it must be the case that S'Size <= X'Size.  This rule does not
      apply to the size of a record component that belongs to subtype S
      but has its size determined by a record representation clause.

   3. In the absence of such a length clause, unless S is an unconstrained
      array subtype or an unconstrained subtype with discriminants,
      S'Size is the minimum value of X'Size for all objects of subtype S,
      except those occurring in records governed by record representation
      clauses.


|>                        Does "minimum number of bits" mean: 
|>
|> a   the size should be given as if pragma PACK had been used, or
|>
|> b   the size should be the least upper bound of the size of all objects of
|>     this (sub)type with all possible combinations of discriminant values.
|>
|> Or does it mean both? or something else entirely?

AI-00536 does not cover unconstrained subtypes with discriminants.
(AI-00825 was a preliminary draft of a proposal to cover such subtypes,
but no action was ever taken on this draft and it has no official
status.)  Because of point 2, there are cases where the 'Size for the
subtype can be less than the l.u.b. of the 'Size values for all objects
of the subtype: 

   type T is -64 .. 63;
   for T'Size use 7;

   type A is array (1 .. 10) of T;
   pragma Pack(A);

Even with the Pack pragma a compiler is allowed to include a padding bit
in each array component, so that T'Size = 7 but X'Size = 8 for all
objects of type T, including components of A.

|> We have a compiler here that implements something like (a). For example, a
|> record type (no discriminants) has 'SIZE 688, but a variable of that type has
|> 'SIZE 704. What is this useful for? (This compiler is not generally available
|> and I am not free to identify it - for those who know, it's named after an
|> endangered species.)

(Ah, of course!  The Smallpox Compiler is known to behave this way. :-) )

Since 688 bits is 21.5 32-bit words and 704 bits is 22 32-bit words,
the discrepancy can be explained by padding the record to a fullword
boundary.  The 'Size for the type indicates that you should be able to
pack an array of 10 of these records into 6,880 bits.

|> Q2. What should 'SIZE give for a variable which is a formal parameter of a
|> sub-program? The same as when appliefd to the actual parameter?

Not necessarily.  Pass by copy is allowed and the actual may be a
component of a packed array.

|> Q3. Might 'SIZE work differently in any respect if the (sub)type or object
|> concerned is a formal parameter of a generic?

Yes.  For example, implementations in which instances of a given generic
execute the same shared code will use the size of the largest
floating-point type for any generic formal floating-point type.

--
Norman H. Cohen    ncohen@watson.ibm.com