Allocation of local constant arrays

Allocation of local constant arrays

[Davide]

Hi,

suppose to have a constant array declared inside a procedure. Suppose to
perform, inside that procedure, a loop in which the elements of the constant
array are accessed sequentially until some condition become true.
My question (i know it's a newbie question...): is the local constant array
copied into the stack each time the procedure is called or it is allocated
once and for all in some part of the memory? I'm using AdaMulti compiler.

Thank you.

Davide.

Re: Allocation of local constant arrays

[Davide]

"Davide" <ppp@ppp.it> ha scritto nel messaggio
news:c8ft6t$gt9$1@e3k.asi.ansaldo.it...
> Suppose to
> perform, inside that procedure, a loop in which the elements of the
constant
> array are accessed sequentially until some condition become true.

just a clarification. I mentioned that loop because I think in that case the
compiler cannot insert, where referenced, the constant values of the array
directly into the generated machine code.

Re: Allocation of local constant arrays

[Robert I. Eachus]

Davide wrote:
> Hi,
> 
> suppose to have a constant array declared inside a procedure. Suppose to
> perform, inside that procedure, a loop in which the elements of the constant
> array are accessed sequentially until some condition become true.
> My question (i know it's a newbie question...): is the local constant array
> copied into the stack each time the procedure is called or it is allocated
> once and for all in some part of the memory? I'm using AdaMulti compiler.

Some compilers can store such an array in the data segment.  But if you 
care, and copying is an issue, put the array in a library level package.

One of the most powerful optimization "tricks" in Ada is that you can 
put data in in structures  inside library packages that would have to be 
allocate on the heap as in C, or nested inside a procedure or function.

It is sometimes tricky to do all this before the main program executes, 
but it can be done.  And it is great during debugging of mathematical 
packages to be able to read the tables from a file, then compile them 
into the final package when debugging is done.  A good example is the 
inverse normal function.  The best approach is to use different 
(approximation) algorithms for different parts of the function.  It is 
nice to be able to test the various cut-points and interpolation 
constants without recompiling, then put everything as constants in the 
package body.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Allocation of local constant arrays

[Davide]

"Robert I. Eachus" <rieachus@comcast.net> ha scritto:

> then put everything as constants in the
> package body.

As a general way to design the software, if you have constants used only by
a procedure, do you prefer (for the final application) to nest them in that
procedure or to keep them together with all the other constants in the
package body, then visible also to procedures not referencing them?

The question, in other words,  is: locate the data closest as possible to
operations who used them or tend to "globalize" their visibility also when
not necessary?

Waiting for opinions.

Davide.

Re: Allocation of local constant arrays

[Martin Krischik]

Davide wrote:

> 
> "Robert I. Eachus" <rieachus@comcast.net> ha scritto:
> 
>> then put everything as constants in the
>> package body.
> 
> As a general way to design the software, if you have constants used only
> by a procedure, do you prefer (for the final application) to nest them in
> that procedure or to keep them together with all the other constants in
> the package body, then visible also to procedures not referencing them?
> 
> The question, in other words,  is: locate the data closest as possible to
> operations who used them or tend to "globalize" their visibility also when
> not necessary?
> 
> Waiting for opinions.

Normally I put them with the procedure. Sometimes I put them in packages
inside the procededure:

procedure Proc
is
  package Pack
    ...
  end Pack;
begin
...

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Allocation of local constant arrays

[Freejack]

On Thu, 20 May 2004 13:24:07 +0200, Martin Krischik wrote:

> 
> Normally I put them with the procedure. Sometimes I put them in packages
> inside the procededure:
> 
> procedure Proc
> is
>   package Pack
>     ...
>   end Pack;
> begin
> ...
> 
> With Regards
> 
> Martin


Wouldn't that kind of declaration essentially make the variables static
constants, unchangeable from one call of the procedure to another. And
would I reference the var as Proc.Pack.foobar or just Pack.foobar?

Although it looks like this type of definition would help the compiler
perform optimizations.

Freejack

Re: Allocation of local constant arrays

[Martin Krischik]

Freejack wrote:

> On Thu, 20 May 2004 13:24:07 +0200, Martin Krischik wrote:
> 
>> 
>> Normally I put them with the procedure. Sometimes I put them in packages
>> inside the procededure:
>> 
>> procedure Proc
>> is
>>   package Pack
>>     ...
>>   end Pack;
>> begin
>> ...
>> 
>> With Regards
>> 
>> Martin
> 
> 
> Wouldn't that kind of declaration essentially make the variables static
> constants, unchangeable from one call of the procedure to another.

Yes. But beware: if Pack had an evaluation code it would be called with each
call to Proc.

> And 
> would I reference the var as Proc.Pack.foobar or just Pack.foobar?

Both can be used.
 
> Although it looks like this type of definition would help the compiler
> perform optimizations.

That's the idea. Usually I just trust the compiler to do it right.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Allocation of local constant arrays

[Steve]

My opinion:
  It depends on the constants.

  If the constants are configuration values that someone might need to
change during maintenance, I tend to locate these values in an area near the
beginning of the package along with an explanation of their use.  This makes
it convenient for the maintainer.

  If the constants never change and are only relevent to the local function
or procedure, I tend to locate these values within the function or
procedure.

Steve
(The Duck)

"Davide" <ppp@ppp.it> wrote in message
news:c8hvcl$eth$1@e3k.asi.ansaldo.it...
>
> "Robert I. Eachus" <rieachus@comcast.net> ha scritto:
>
> > then put everything as constants in the
> > package body.
>
> As a general way to design the software, if you have constants used only
by
> a procedure, do you prefer (for the final application) to nest them in
that
> procedure or to keep them together with all the other constants in the
> package body, then visible also to procedures not referencing them?
>
> The question, in other words,  is: locate the data closest as possible to
> operations who used them or tend to "globalize" their visibility also when
> not necessary?
>
> Waiting for opinions.
>
> Davide.
>
>

Re: Allocation of local constant arrays

[Robert I. Eachus]

Davide wrote:

> As a general way to design the software, if you have constants used only by
> a procedure, do you prefer (for the final application) to nest them in that
> procedure or to keep them together with all the other constants in the
> package body, then visible also to procedures not referencing them?
> 
> The question, in other words,  is: locate the data closest as possible to
> operations who used them or tend to "globalize" their visibility also when
> not necessary?
> 
> Waiting for opinions.

Never really thought about it.  Usually if I am creating a library the 
constant arrays will be used by several functions, so of course I put 
them in the package body to have a single copy.

As for "cut-points" in algorithms, usually these are named numbers in 
Ada terms.  The compiler will normally put them into the code segment, 
so where they are allocated is not an issue.  And I guess I like to have 
all the miscellanous cruft that needs a descriptive block comment in the 
area where the approach taken by the package as a whole is explained.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush