Static in 9X

Static in 9X

[Ken Garlington]

I'm trying to work a problem with my Ada vendor, and time is short, so I would
appreciate any help I can get in the next day or so. Part of my problem is
understanding the definition of "static" in the 9XRM 4.9. Which (if any) of the
following are static, and under what conditions/assumptions? (Assume that
exceptions are not a factor.)

1. A constant composite value, with static initial values, e.g.

   type R is record
     X : INTEGER;
     Y : INTEGER;
   end record;

   REC : constant R := (1,2); -- static?

2. Components of a record/elements of an array, e.g.

   V : constant INTEGER := REC.X; -- static?

3. A user-written function, e.g.

   function Z return INTEGER is begin return 0; end; -- static?

4. Type conversions that require manipulation of the form of the data; e.g.

   X : constant FLOAT := 0.0;
   Y : constant LONG_FLOAT := LONG_FLOAT(X); -- static?

5. UNCHECKED_CONVERSIONs?


Thanks in advance for anyone who can help.


Ken Garlington
Lockheed Fort Worth Company

Re: Static in 9X

[Robert Dewar]

These seem very straightforward questions, answered in an accessible
way by the rules in the RM (and note I am not one to generally say
that the 9X RM is easy to read).

1,2,3,5 are of course non-static. I have no idea why anyone would think
that the rules in the RM even suggest for a moment that they are static,
so it is hard to quote specific rules. The RM rules basically say what
*is* static, and none of these rules cover any of these cases.

4 is static, because of para 9 ("a type conversion whose subtype mark denotes
a static scalar subtype, and whose operand is a potentially static expression)

I don't see that an Ada vendor is particularly in the business of 
interpreting language rules like this, though in practice quite a few
"bugs" submitted are just misunderstandings of the language (we find this
in GNAT bugs for example).

What would be useful is for you to explain why you thought that the
other cases (1 = composite type, 2 = record field, 3 = user defined
function, 5 = unchecked conversion) were possibly covered by any
of the items in paras 3-12. That might give a clue as to something
that is not as clear as it should be in the RM.

Re: Static in 9X

[Tucker Taft]

In article <940914130023_73672.2025_DHR31-2@compuserve.com>,
Ken Garlington  <73672.2025@COMPUSERVE.COM> wrote:

>I'm trying to work a problem with my Ada vendor, and time is short, so I would
>appreciate any help I can get in the next day or so. Part of my problem is
>understanding the definition of "static" in the 9XRM 4.9. Which (if any) of the
>following are static, and under what conditions/assumptions? (Assume that
>exceptions are not a factor.)
>
>1. A constant composite value, with static initial values, e.g.
>
>   type R is record
>     X : INTEGER;
>     Y : INTEGER;
>   end record;
>
>   REC : constant R := (1,2); -- static?

No.

>2. Components of a record/elements of an array, e.g.
>
>   V : constant INTEGER := REC.X; -- static?

No.

>3. A user-written function, e.g.
>
>   function Z return INTEGER is begin return 0; end; -- static?

No.

>4. Type conversions that require manipulation of the form of the data; e.g.
>
>   X : constant FLOAT := 0.0;
>   Y : constant LONG_FLOAT := LONG_FLOAT(X); -- static?

Yes, this is one of the changes in Ada 9X (see below).

>5. UNCHECKED_CONVERSIONs?

No.

The interesting changes in type conversions from Ada 83 can be 
summarized as follows:

  1) Type conversions are static if the target is a static scalar 
     subtype and the operand is static;

  2) Short circuit operations are static if the operands are both
     (potentially) static;

  3) Membership tests are static if the operand is static and
     the range or subtype is static;

  4) String literals and concatenations of static operands returning
     a string type are static (but 'value and 'image are never
     static).

  5) The bounds/length of an array object or array subtype are static
     if the object/subtype is statically constrained.
     

This is enumerated in the AARM-4.9(41.a .. 47.a);5.0.

If you don't want to wade your way through the AARM for this,
you can look at the "Changes from Ada 83 to Ada 9X" document
available on ajpo.sei.cmu.edu in public/ada9x/rm9x/v5.0/ch83_9x.{doc,ps}

>Thanks in advance for anyone who can help.
>
>
>Ken Garlington
>Lockheed Fort Worth Company

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Static in 9X

[Tucker Taft]

By the way, in private conversation it became clear
that the real goal was more link-time initialization of
large data structures.  Although staticness is only defined
for scalars and certain string expressions, there is no
reason an implementation should not be *much* more aggressive
in performing link-time initialization of data structures.

RM9X does talk about preelaborability, which is closer to
what is appropriate for link-time initialization, but even
preelaborability is too conservative in many cases (and a bit
too liberal in others).

The goal of every Ada implementation should be that if there
is no calculation that *needs* to be performed at run-time to
initialize a data structure, then the data structure should 
be link-time initialized.  Of course no implementation can
really fulfill this goal -- it is probably equivalent to solving
the halting problem -- but this should be the goal.

The user can help out by avoiding things like:

  1) anything that depends heavily on the run-time system
     (such as uses of allocators, anything tasking-related, etc.)
     and hence might involve building up linked lists, etc.

  2) references to other variables or large constants in the
     aggregate initializing a large constant you hope will
     be link-time initialized.  Just because something is
     link-time initialized, *don't* presume the compiler can
     perform indexing or selection into it at compile-time,
     because that implies keeping all of the data in memory,
     rather than just dumping it into the object module.
     For example:
         X : constant Blah := (1, 5, 8, 7, "abcde", 3.5, ...);
         Y : constant Boffo := (4, 7, X.F, 9, X.G, 2.7, ...);

     Expecting X to be link-time initialized is reasonable.
     Expecting Y to be is not, given the references to X inside it.

  3) Any calls on user-defined functions, even if their bodies are
     "trivial" or inlined.

Probably some compilers can handle even things like the above.  In 
particular, there is a recommendation that allocators for 
access-to-constant types be handled at link-time, and I hope
most Ada 9X compilers will do so.  This should enable tables of
pointers to error messages (or equivalent) to be link-time initialized.  
For example:

    type Error_Message is access constant String;
    Error_Table : array(Positive range <>) of Error_Message :=
      (new String'("Naughty, naughty"),
       new String'("No way, Jose'"),
       new String'("You have got to be kidding"),
       ...
      );

The above should be link-time initializable.  For those familiar
with C and how string literals are represented (by a pointer
into link-time allocated storage), the above should be treated as
approximately equivalent to:

     char *error_table[] = {
        "Naughty, naughty",
        "No way, Jose'",
        "You have got to be kidding",
        ...
     };

It is not exactly the same because in Ada, strings have array
bounds rather than a null terminator, but that shouldn't interfere
with link-time initialization of a data structure like the above.

Note that access-to-variable allocators can't be easily handled
with link-time allocation, because unchecked-deallocation is allowed
for access-to-variable types (it is not allowed for access-to-constant
types in 9X).
        
S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Static in 9X

[Ken Garlington]

Robert Dewar <dewar@CS.NYU.EDU> writes on Thu, 15 Sep 1994 09:37:32:

<< I don't see that an Ada vendor is particularly in the business of
interpreting language rules like this >>

Our vendor decides whether or not to put objects in ROM via the definition of
static (in part). We're trying to get better performance in this area for
composite objects.

<< What would be useful is for you to explain why you thought that the
other cases were possibly covered >>

Good question. I don't have the standard in front of me, so I'll have to rely
on memory for some things. I think it says that a name which denotes a scalar
object of a static type with a static value is static. What if the scalar is a
record component?

The discussion on static functions describes predefined functions which have
static arguments. I thought maybe an instantiation of UNCHECKED_CONVERSION
could possibly fit that definition, since UNCHECKED_CONVERSION is predefined.

Most of it was just wishful thinking; that I might not have read something
completely. Records such as:

     type MY_TYPE is record
        X : INTEGER;
        Y : INTEGER;
     end record;

     MY : constant MY_TYPE := (1,2);

just seem so obviously static, in the general (non-Ada) sense of the term, that
I thought there had to be something I'm missing. Similarly, when I look at a
function like

    function ADD ( VALUE : INTEGER ) return INTEGER is
    begin
       return VALUE + 1;
    end;

    V : constant INTEGER := ADD(0);

it seems like ADD(0) should be a static expression. I understand that "static"
in the Ada sense probably wasn't meant to be related to ROMability, but that's
where we are with the vendor at the moment.

The question about type conversions is a little different. The vendor says that
a type conversion that requires manipulation of the data representation can't
be put in ROM. However, 9X seemed to me to define this as static in some cases.
I just wanted to make sure I read it right.

Re: Static in 9X

[Robert Dewar]

"Our vendor decides whether or not to put objects in ROM via the definition of
static (in part). We're trying to get better performance in this area for
composite objects."

Have a little chat with your vendor. We are talking 9X here right? It is
clear that preelaborability should be the issue (see the systems
programming annexe). Whether something is static should have nothing
whatever to do with whether things are static.

Re: Static in 9X

[Ken Garlington]

It appears that both Robert Dewar and Tucker Taft believe that the issue of
whether or not objects can be placed in ROM is generally unrelated to the issue
of whether or not the expression is static. Since we also originally asked our
vendor not to use "static" as a basis for their proposal, we must understand
Ada better than I thought! :)  Now, if we can only get our _vendor_ to accept
this profundity at our next meeting...

While I'm at it, I also wanted to thank Mr. Taft for explaining the difficulty
of optimizing an expression initialized with a previosuly-defined constant
composite/attribute. Although the problem of keeping the composite in memory
long enough wouldn't necessarily be a problem for a VAX/1750A cross-compiler
(generally, the most data that could be in one package on a 1750A is 32K, which
a VAX can certainly support), I can see that the practice of using common
compiler components for multiple host/target combinations would make it
difficult to do this in practice.