In a message dated 03-22-97, Henk den Adel said to Mike Phillips about Trap
0005

Hi Henk,

 MP> The reason is that the compiler does not know how large to make the
 MP> stack, so it uses a default size.

HA>Now i'm puzzled. Maybe you can help me out of the maze. The way i was 
HA>thinking is as follows. Languages like C urge one to 
HA>declare variables, in contrast to e.g. Fortran, where the 
HA>motto is: if you need one, just use it, you don't have to 
HA>declare it. So there must be a reason for the necessity to 
HA>declare variables in a language like C.

C/C++, just like ALGOL 60, ALGOL 68 and Pascal require the programmer to
declare a variable, to ensure it receives the correct type.

In FORTRAN, an undeclared identifier is assigned a type based on the first
letter of its name: I-N means INTEGER*4 and A-H,O-Z means REAL*4, unless
these defaults are overridden by an IMPLICIT statement.

HA>Another fact: all 
HA>declarations must be contained in the first part of a 
HA>function, before the first executable statement, i.e.

HA>   float x, y;
HA>   y = sin(x);
HA>   int i;

HA>produces an error during compilation. Why?

To facilitate one-pass compilation.

If all the variables in a function are required to be declared before any
executable code appears, actual object code can be generated as each
executable statement is encountered.

HA>I think the compiler wants its
HA>variables neatly bundled, so it can allocate adresses and 
HA>the accompanying amount of memory, without having to gather 
HA>variables all over the place.

No. For automatic storage the addresses are not known at compile time. Only
an offset into the current stack frame (no, _not_ the stack segment!) is
known.

HA>Furthermore, since 
HA>sizeof(struct whatsoever) produces the right size of more 
HA>complex type of variables, such as structs, the compiler 
HA>should be able to determine the amount of memory which is 
HA>needed for a struct, by sheer interpretation of the formal 
HA>declaration of the struct, as provided in the function or 
HA>its include files. BTW, i have declared my struct as a 
HA>variable, not as a pointer.

This will enable it to determine the size of the stack frame for that
function. However, this is only part of the overall stack size required.

HA>Could you be so kind to indicate which step in my reasoning is incorrect?

Also, the compiler cannot know the stack requirements of any functions that
are linked in from .LIB files.

The amount of stack required is the total of all the stack frames that are
in use at the deepest level of function call. This is not the same as the
sum of all the stack frames in the compilation unit, since it doesn't
include those for .LIB-linked routines, and the actual depth of call is
determined by the execution sequence of the code.

 MP> That function needs 40k of stack. What if that function called a function
 MP> in another source file that needs another 40k of stack. How is the
 MP> compiler to know this?

HA>Just add another 40 kB of stack?

But the compiler doesn't know what the requirements are of modules not in
the current compilation unit. Since Mike says that the called routine is in
another source file, which might be on another machine, since only the
object code is needed by the linker.

 MP> Anyways, it's the linker that actually makes the stack definitions, and
 MP> it doesn't know how much you've used.

HA>In my opinion the compiler can determine how much memory is needed to
HA>contain the variables which have been declared.

Only those declared in the source file currently being compiled. Even then,
it cannot know where they will be placed in the stack area.

The compiler can only determine the size of a stack frame for a single call
of the function.

Recursive calling means that many instances of this stack frame will be
allocated concurrently. The exact number of instances cannot be determined
at compile time.

Even when recursion is not involved, the location from where a function can
be called cannot be determined at compile time, so the depth of call prior
to allocating the function's stack frame cannot be known. As a result, the
depth to which a given stack frame will push the overall stack cannot be
known either.

Determining the maximum stack size at compile time is an incalculable
problem.

A simple kludge would be to calculate the total amount of static storage
required (only the linker knows this, not the compiler), subtract it from
the total address space and make that difference the stack size. Thus, if
your program occupies 32,768 bytes (32KB) under OS/2 you will receive a
default stack of 503,316,480 bytes, which should be enough for anybody [just
like 640KB!]. Of course, this might crash if you try to load a DLL into the
tiled area. ... ;-)

HA>Isn't that it what 
HA>declarations are meant for? I can't believe the more 
HA>misantropic suggestion: to be able to generate error 
HA>messages when an unfortunate programmer forgets a variable 
HA>to declare?

Anybody who has had to debug someone else's FORTRAN will know that this is
not misanthropic. Assumed data types for undeclared variables can be a major
problem. The restriction also catches typo's in variable names that make
them seem undeclared to the compiler.

 MP> Just make your stack large enough.

HA>Murray Lesser wrote me that excessive stack does not hurt 
HA>my resources, if the compiler is good, so that will be the 
HA>solution.

That is the reasoning behind "sparse" stack allocation.

Just allow the program to use a huge amount and let it commit page frames of
memory as it needs them. That is why Murray's program with 2MB of stack
consumes only 216KB of real memory.

Regards

Dave

___
 * MR/2 2.25 #353 * "Do your parents *know* you are Ramones?" - Ms. Togar

--- Maximus/2 3.01