Re: static objects in ADA

Re: static objects in ADA

[dennison]

In article <YsRFDEAtZbH3EwNc@tioman.demon.co.uk>,
  Mark Elson <marke@tioman.demon.co.uk> wrote:
> Hi,
>
> I'm a C++ programmer who is new to ADA. I've looked briefly in the Ref
> Manual and the FAQ but I can't find the answer to the following question
>
> 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?

Sure. Declare them in the package body that your routine is declared in
instead of in the routine itself.

Unless you have a really large initialized object, it shouldn't make too much
difference in runtime performance though.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: static objects in ADA

[Stephen Leake]

Mark Elson <mark@tioman.demon.co.uk> writes:

> Hi,
> 
> I'm a C++ programmer who is new to ADA. I've looked briefly in the Ref
> Manual and the FAQ but I can't find the answer to the following question
> 
> 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?

There is no keyword in Ada that means something similar to this
meaning of 'static' in C++, but you can easily declare objects that
are "created at link time rather than at run-time":

package body Stuff is

   State : State_Type;
   Count : Integer;

end Stuff;

Assuming State_Type is a plain record type (not derived from
Ada.Finalization.Controlled, not a task type, not a protected type),
these objects simply occupy data space; they have no run-time creation
code. Note that it is possible to do a similar thing in C++; in that
case, State_Type must be a plain struct with no constructor.

> 
> I am working on an embedded app which has a very short "boot-up" time
> requirement (10 to 20 ms). I am being told that using objects will
> greatly increase my app start time because of object creation overhead.
> Any comments appreciated.

In Ada, you have complete, direct control over all aspects of object
creation. The keyword 'new' must be used to dynamically create an
object (as it must be in C++). 

-- Stephe

static objects in ADA

[Mark Elson]

Hi,

I'm a C++ programmer who is new to ADA. I've looked briefly in the Ref
Manual and the FAQ but I can't find the answer to the following question

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?

I am working on an embedded app which has a very short "boot-up" time
requirement (10 to 20 ms). I am being told that using objects will
greatly increase my app start time because of object creation overhead.
Any comments appreciated.

TIA
-- 
Mark Elson

Re: static objects in ADA

[Marin David Condic]

Mark Elson wrote:
> 
> Hi,
> 
> I'm a C++ programmer who is new to ADA. I've looked briefly in the Ref
> Manual and the FAQ but I can't find the answer to the following question
> 
> 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?
> 
> I am working on an embedded app which has a very short "boot-up" time
> requirement (10 to 20 ms). I am being told that using objects will
> greatly increase my app start time because of object creation overhead.
> Any comments appreciated.
> 
The answer is, "It Depends" - There are definitely ways of insuring that
allocation of objects or constants are done at link time, but you may
still need to look at what your specific compiler does. For example, if
you declare an object in a package specification, the allocation and
initialization *could* be done statically without requesting anything
else. However, I've seen cases where the initialization is *not* done
statically. (Language rules can make this difficult because you have to
detect cases where, for example, functions have to run at elaboration
time to perform the initialization. So some compilers just make
everything work that way.)

What you will want to do is declare your objects in a package. Things
declared in a library level package are basically "static" in terms of
allocation. The difficult issue is if you are giving initial values to
the objects and/or making them constants. Here you have issues of when
the initialization is performed. If you don't initialize, then there is
not likely an issue.

Object creation "greatly increasing" your start up time may very well be
a myth. If all you want is some integers that are globally accessible
and are not allocated off the stack, then a library level package is the
place to put them. However, allocating the same integers off the stack
at subprogram invocation is not terribly expensive either. What usually
is going to cause you trouble is either dynamic allocation (using access
types - "pointers") which has to go get memory from the heap or the
initialization of the objects which may be done dynamically at start up.
I had a case with an older Ada83 compiler where it wanted to perform
initialization of constants at start up, but the constants needed to
live in EEPROM. We had to go through some gyrations to get the
initialization done statically. 

In general, if you don't do anything tricky with object declarations in
a library level package, you shouldn't experience any more overhead than
similar declarations in other languages.

You may also want to investigate the pragma Volatile (See appendix C.6
of the ARM) since this will force all reads/updates of the objects to be
done in memory. This is important if you don't want the optimizer
keeping the value in registers or simply optimizing the object away
altogether.

I'm not sure if there is an "Ada Standard" way to force the compiler to
allocate *and initialize* objects at link time (pragma Pure? pragma
Elaborate? pragma Preelaborate? See ARM 10.2, 10.2.1), but generally for
simple objects in a library package with static initializations (and
possible use of Volatile) you get what you would expect. You may still
have to deal with the linker and if you can state what your compilation
system is, someone on this group will probably know how to handle that.

I hope this helps

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: static objects in ADA

[Samuel Mize]

[ 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

Re: static objects in ADA

[Mark Elson]

First of all thanks to all who replied to this thread, they have all
been very useful especially Sam's


>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 slipped up here in my terminology - whilst I was thinking of static
initialisation being at compile/link time the relevant C++ keyword is
actually const. What prompted me to think of this approach is the common
use of const character arrays to store config control info as strings in
object files.

>> 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.

You're quite right - virtual functions can be called through pointers or
references to automatic variables (so long as they still exist, of
course).

The "advice" has really annoyed me. It came from Green Hills and they
were actually telling us that we should abandon an object-orientated
design and use structured methods instead to avoid the overhead of
object initialisation (which they believed would give us "long" start-up
times). In fact, we are not creating any significantly large objects at
start-up time, anyway, so I felt this was very bad advice. IMO, at the
implementation level OO and structured methods might only differ in the
organisation of code. There should be no reason why OO-designed code
should be inherently less efficient than a structured design. Possibly
inefficient activities such as dynamic memory allocation can be avoided,
by design, if required. In fact we intend to do this for other reasons
as the app will be safety-critical.

Thanks again for the replies.
-- 
Mark Elson

Re: static objects in ADA

[Robert Dewar]

In article <4IaN6CA84vI3EwTh@tioman.demon.co.uk>,
  Mark Elson <marke@tioman.demon.co.uk> wrote:
> I slipped up here in my terminology - whilst I was
> thinking of static initialisation being at compile/link
> time the relevant C++ keyword is
> actually const. What prompted me to think of this
> approach is the common
> use of const character arrays to store config control
> info as strings in
> object files.

As far as I know, there is no requirement in C++ that
const objects be initialized at link time. Such a
requirement is pretty hard to state, since at the level
of a semantic definition, such a distinction has no
semantically observable effects.

In practice, C++ compilers very reasonably do what you
expect ...

In the case of Ada, pragma Preealborate is intended to
have much the same effect, but here to, it is impossible
to guarantee that you get link time initialization, since
this is hard to talk about, and the best we can do in Ada
is the following "requirement":

  3   The implementation shall not execute any memory write
      operations after load time for the elaboration of
      constant objects declared immediately within
      the declarative region of a preelaborated library
      package, so long as the subtype and initial
      expression (or default initial expressions if
      initialized by default) of the object_declaration
      satisfy the following restrictions. The meaning of
      load time is implementation defined.

The "implementation defined" at the end is of course a
worry, but it is unavoidable, any attempt to formally
define load time would fail.

In practice, if you write

     type x is array (0 .. 100_000_000) of boolean;
     vx : x := (others => False);

I would guess many implementations would output object
code that would expand this as part of loading on a system
where to do otherwise would generate a gigantic 100 meg or
bigger load module.

In GNAT we have provided the additional restrictions
identifier:

  pragma Restrictions (No_Elaboration_Code);

which really means what it says, and if you use this, you
can be sure that you have NO code at all for runtime
elaboration.

Here is the restrictions pragma in action:

     1. pragma Restrictions (No_Elaboration_Code);
     2. package q is
     3.      type x is array (0 .. 100_000_000) of boolean;
     4.      vx : x := (others => False);
                       |
        >>> violation of restriction "no_elaboration_code"
            at line 1

     5. end q;

If you change the range of the array to something more
reasonable, the message will go away, since the compiler
will be willing to initialize small arrays at link time.

Again, the best advice is contact your vendor, the trouble
with general posts on CLA is that they tend to go in the
wrong direction sometimes :-)

Everyone assumed you were talking about the static scope
issue, when in fact your concern about load time
initialization for safety critical programs was a
completely different one.


Robert Dewar
Ada Core Technologies



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: static objects in ADA

[Matthew Heaney]

Mark Elson <mark@tioman.demon.co.uk> writes:

> 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?

Declare the objects in a static scope (ie package spec or body), without
giving them a default value, and declare the package using pragma
Preelaborate.

package P is
  pragma Preelaborate;
  X : Integer;
end P;

Re: static objects in ADA

[dennison]

In article <4IaN6CA84vI3EwTh@tioman.demon.co.uk>,
  Mark Elson <marke@tioman.demon.co.uk> wrote:

> The "advice" has really annoyed me. It came from Green Hills and they
> were actually telling us that we should abandon an object-orientated
> design and use structured methods instead to avoid the overhead of
> object initialisation (which they believed would give us "long" start-up
> times). In fact, we are not creating any significantly large objects at
> start-up time, anyway, so I felt this was very bad advice. IMO, at the
> implementation level OO and structured methods might only differ in the
> organisation of code. There should be no reason why OO-designed code
> should be inherently less efficient than a structured design. Possibly
> inefficient activities such as dynamic memory allocation can be avoided,
> by design, if required. In fact we intend to do this for other reasons
> as the app will be safety-critical.

Compiler developers are notoriously anti-OO. Perhaps that is because of all
the extra work those OO features cause them. :-)

Hopefully this is a comment on their perception of OO-designed code, and not
on their compiler's efficincy in translating tagged-type code into machine
language. Our current project is realtime, is using a GreenHills compiler,
and it is OO through and through. But then, we don't really care too much
about startup time either.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: static objects in ADA

[Robert Dewar]

In article <7g1uvn$fjr$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> Compiler developers are notoriously anti-OO. Perhaps that
> is because of all the extra work those OO features cause
> them. :-)

What a completely bizarre (and completely unsupportable)
claim. Perhaps you have had the bad fortune to run into
one or more particular developers with this incompetent
attitude, but to generalize it to all developers is
unreasonable.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: static objects in ADA

[Mark Elson]

In a previous posting in this thread I attributed some advice to abandon
OOA&D (because object creation would take a long time) to avoid "long"
app initialisation times to Green Hills. The information came via a
third-party and it was seems there was a mis-understanding - the advice
didn't come from Green Hills (see bottom).

My sincerest apologies to Green Hills for getting this wrong - at the
time I had been led to believe the advice came from them.

In article <4IaN6CA84vI3EwTh@tioman.demon.co.uk>, Mark Elson
<mark@tioman.demon.co.uk> writes
>The "advice" has really annoyed me. It came from Green Hills and they
>were actually telling us that we should abandon an object-orientated
>design and use structured methods instead to avoid the overhead of
>object initialisation (which they believed would give us "long" start-up
>times). In fact, we are not creating any significantly large objects at
>start-up time, anyway, so I felt this was very bad advice. IMO, at the
>implementation level OO and structured methods might only differ in the
>organisation of code. There should be no reason why OO-designed code
>should be inherently less efficient than a structured design. Possibly
>inefficient activities such as dynamic memory allocation can be avoided,
>by design, if required. In fact we intend to do this for other reasons
>as the app will be safety-critical.
>
>Thanks again for the replies.

Message from 3rd party:

The advise to abandoned object orient programming came from a person who
programmed in ADA and not from Green Hills employee. This person has had
some experience in real time systems like ours but had not had to deal
with
the boot up time constraint. They were working with ADA 83 and not ADA
95.
From my understanding ,ADA 83 is not a true OO language like ADA 95.His
experience with ADA 83 was to convert existing FORTRAN code to what is
referred to as ADATRAN. This "form" of ADA is not OO in nature. It is
FORTRAN programming using ADA syntax. Because of what we need to do in
the
time allotted, he felt that maybe we would need to take the same path.
After talking to the Green Hills ADA people we have a better
understanding
of what ADA 95 is and what it is capable of doing. I believe we can use
ADA95 as it was intended.



-- 
Mark Elson

Re: static objects in ADA

[dennison]

In article <BQBDMIABDnM3EwVb@tioman.demon.co.uk>,
  Mark Elson <marke@tioman.demon.co.uk> wrote:

> of what ADA 95 is and what it is capable of doing. I believe we can use
> ADA95 as it was intended.

This last sentence is the best news in the whole posting. You would find few
things in life more frustrating than trying to program Fortran code in Ada.
Good luck to you.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own