Re: obj'size for constants

Re: obj'size for constants

[Robert Dewar]

Tell the pesky user to buzz off. It is clear that returning 0 is OK,
raising Program_Error might be even kinder, since the user is doing
something that makes no sense whatsoever.

Note that in 9X, you could specify that the constant is aliased, in 
which case, it is in memory and has an address.

Re: obj'size for constants

[John Goodenough]

In article <1993Sep7.181330.3952@ocsystems.com>, kdh@ocsystems.com (Kevin D.
Heatwole - OC Systems Inc.) writes: 

|>   Consider:
|> 
|>        one : constant integer := 1;
|> 
|> and integer'size = 32.  What are legitimate values that an implementation
|> may return for one'size?
|> 
|> I have read AI-00536 and it seems fairly clear that "if X is an object of
|> subtype S, then X'Size >= S'Size" so one'size should equal 32 (at least).
|> But, the LRM states that p'size yields the number of bits allocated to hold
|> the object.  In our implementation, scalar constants are replicated at use 
|> and rarely have any bits allocated to them at runtime (in this case, one
|> would most likely be represented in the hardware instruction (probably as
|> part of the op-code), rather than allocated in data memory).
|> 
|> In reading AI-00536, it doesn't seem that the authors considered this case

This is true.  We were concerned with other issues.

|> The reason I ask this question is that we are maintaining an Ada compiler
|> which returns the actual number of bits reserved for the object in memory
|> (e.g., one'size = 0), but a pesky user has filed a defect indicating that
|> the result should be the same as type'size for constants (e.g., one'size = 3
2).
|> We must fix all reported defects (if legitimate), but I would rather leave
|> the current behaviour as it is.

The short answer is that in this specific case it is certainly legitimate to
return zero for ONE'SIZE if the object is in fact not allocated any space as
an object.  Lawyerly arguments follow.

AI-00536/08 says in the first paragraph of its summary (which also serves as
the official recommendation):

    'SIZE applied to an object yields the number of bits allocated for the
    object.

This just replicates the basic statement in the RM.  The rest of the summary
does not specify what the value of ONE'SIZE should be, because it deals with
the size of objects whose type or subtype size has been specified with a
length clause (not the case for this example) or the size of a type or subtype
when no length clause has been given (irrelevant to this example).  Finally,
the last paragraph of the summary states:

    An implementation shall describe, in Appendix F, how the value of 'SIZE is
    determined for objects, types, and subtypes.

Your implementation can say the value of 'SIZE for objects like constants is
determined based on whether the constant is materialized in storage.

The above is basically the answer to your specific question.  But there are a
few complications.  In particular, the final paragraphs in the discussion
section of the AI do seem to address your case:

    In short, when no size has been specified for a type T or a first named
    subtype T and T is not an unconstrained array type or an unconstrained
    type with discriminants, the following relationships must hold when S is a
    subtype of T and OBJ is declared with the subtype indication S:

	       ...

	    .  OBJ'SIZE >= S'SIZE unless OBJ is a component of a record and a
	       component clause is given for OBJ.  In this case, OBJ'SIZE is th
e
	       number of bits specified in the component clause, and this numbe
r
	       may be smaller than S'SIZE or T'SIZE (see AI-00551).

This part of the discussion was intended to explore the ramifications of the
recommendation and it failed to take into account the freedom to return zero
as the size of an object that is not allocated any space at all, due to
optimizations.  Since the discussion section of an AI has no official force,
this oversight is not too significant.  There is no doubt in my mind that if
'SIZE for constants had been considered explicitly by the ARG, the discussion
in this AI would have been modified to say clearly that zero is an acceptable
value when objects are not allocated any storage at all.

Of course, the AI as currently written says that if the size of a type has
been specified with a length clause, then all objects of the type are
allocated at least the specified number of bits (except in certain record
objects).  I also have no doubt that if optimizations had been considered, the
relevant paragraph of the summary would have been changed to say clearly that
if no space is allocated for an object, OBJ'SIZE should return zero; it was
not the intent of the ARG to require that objects be materialized as a side
effect of specifying the size of the object's type.

Finally, since this analysis hasn't been reviewed or approved by anyone, it
has no official force, but it does reflect my considered opinion of what an
"official" response would be.  I hope this is helpful.

John Goodenough
Chair, Ada Rapporteur Group

obj'size for constants

[Kevin D. Heatwole - OC Systems Inc.]

Any of you Ada "language lawyers" out there have an opinion on this one:

  Consider:

       one : constant integer := 1;

and integer'size = 32.  What are legitimate values that an implementation
may return for one'size?

I have read AI-00536 and it seems fairly clear that "if X is an object of
subtype S, then X'Size >= S'Size" so one'size should equal 32 (at least).
But, the LRM states that p'size yields the number of bits allocated to hold
the object.  In our implementation, scalar constants are replicated at use 
and rarely have any bits allocated to them at runtime (in this case, one
would most likely be represented in the hardware instruction (probably as
part of the op-code), rather than allocated in data memory).

In reading AI-00536, it doesn't seem that the authors considered this case
(rather they were mainly concerned with "pad" bits).

The reason I ask this question is that we are maintaining an Ada compiler
which returns the actual number of bits reserved for the object in memory
(e.g., one'size = 0), but a pesky user has filed a defect indicating that
the result should be the same as type'size for constants (e.g., one'size = 32).
We must fix all reported defects (if legitimate), but I would rather leave
the current behaviour as it is.

Thanks for any replies,

Kevin D. Heatwole
OC Systems, Inc.
kdh@ocsystems.com