From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cd962bca2451dfbc X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: static objects in ADA Date: 1999/04/21 Message-ID: <371DED7C.CE52F654@pwfl.com>#1/1 X-Deja-AN: 469162189 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: To: Mark Elson Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-04-21T00:00:00+00:00 List-Id: 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