Re: static objects in ADA

[Samuel Mize <smize@imagin.net>]

[ I apologize if this is redundant, my newsreader failed. ]
[ If you see both, read this one, it's better. --SAM      ]

Mark Elson asked:
> Is there an equivalent declaration (in ADA 95) to the static used in
> C++, i.e. so that objects are created at link time rather than at run
> time?

Depends on what you mean.

Vocabulary: I'll use "C-static" to refer to the "static" variables of
C and C++.  "Static" is used differently in the Ada manual.

As others have told you, Ada variables declared in a library package
spec or body (not contained in a procedure or function declaration)
are C-static.


> I am working on an embedded app which has a very short "boot-up" time
> requirement (10 to 20 ms).

C-static variables are NOT created at link time.  They are just
guaranteed to exist throughout the execution of your main program.

They are created either when the program is loaded, or just before
before "main" runs.  If created at load time, you MAY get a start-up
advantage.  It depends on your compiler/linker/loader.  Here's why.

To create variables, memory must be allocated, and initial values set.

Memory allocation should be very fast.  All the C-static variables
should be allocated in one pointer addition, and all the local
variables in your main program should be allocated in one more
pointer addition.  So for memory allocation, it makes no difference
in start-up time whether your variables are C-static or part of main.

Even for variables used by a subprogram, making them C-static will
only eliminate two stack-pointer adjustments per subprogram call.  

However, there is a time issue with initial values.  Depending on
your linker and loader, the file to load may be an image of the
memory space to be used, including initial values for C-static
variables.  Or, it may just tell the linker how much space to
allocate, and let the program execute code to set any initial values.

Loading a memory image can give a faster start-up when the initial
values can be precomputed.  This is especially true if the software
will be loaded into memory and then sit there waiting for "boot-up,"
since all the C-static variables will already exist at that point.

However, loading an image is no faster for uninitialized variables,
or for those with initial values that must be computed at run-time.

If you must include loading time, images may be slower.  For example,
memory for an uninitialized array of 10,000 integers can be allocated
in a single instruction.  An image-based loader, however, might have
to copy 10,000 garbage values from the load file to memory.

A clever compiler/linker/loader suite might use an image for any
C-static variable whose initial value can be precomputed, and just
allocate memory for any other C-static values.

But then, you can't just re-run a program whose variables are
initialized as part of the executable image.  You have to re-load it
every time.  Some customers will require the ability to restart and
run, and so they will want only constants in the image.

So it's not a simple decision for the compiler vendor, and different
customers will want different answers.  Your compiler/linker may
offer options.  You need to check.

So far, none of this has been specific to Ada.

When you ask your Ada vendor how loading works, ask about support for
the pragma Preelaborate.  This tells the compiler that everything in
the package is preelaborable, which (loosely) means its value can be
determined at link time.  I believe that one intended use of this
pragma is to support pre-loading of initial values.


> I am being told that using objects will
> greatly increase my app start time because of object creation overhead.
> Any comments appreciated.

Hmm.  I wonder if this advice is oriented toward C++.

Vocabulary: I'll reserve "object" for object-oriented entities, that
is, an instance of a class in C++ or a value of a tagged type in Ada.
I'll assume that's what you're talking about here.  I'll use "item"
to mean a regular variable.  The Ada Reference Manual refers to
anything that uses memory (variables, constants, tasks, protected
objects) as an "object."

Perhaps your advice refers to dynamic memory allocation.  I believe
that some object-oriented features in C++ depend on an "object" being
referred to by a pointer, but I didn't think they had to be allocated
at run-time.  That is, I thought you could take the address of an
"automatic" variable and use that.

Or perhaps your advice refers to the run-time execution of the
"constructor" for a class.

In Ada, an "object" is like any other item -- it can be allocated at
run-time on the heap, or as an "automatic" variable (in C terms) on
the stack, or declared in a package.  If the class (in Ada terms, the
tagged type) needs a "constructor," you can use a "controlled" type
and provide an initialization routine.  BUT if you provide initial
values for the object's data, the initialization routine is skipped,
on the assumption that you set the object up correctly.

So if this advice is talking about avoiding objects to avoid the use
of constructor functions, you can often avoid the problem entirely in
Ada.  This is not surprising; Ada's object-oriented features were
designed to be quite efficient for real-time programming.

I hope you find this information overload to be useful.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam