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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: Samuel Mize Subject: Re: static objects in ADA Date: 1999/04/22 Message-ID: <7foacg$3t1@news1.newsguy.com> X-Deja-AN: 469763464 References: Organization: ImagiNet Communications, Ltd. User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2) Newsgroups: comp.lang.ada Date: 1999-04-22T00:00:00+00:00 List-Id: [ 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