scott@CANNON.CS.USU.EDU (Scott Cannon) (05/16/91)
Here's an interesting quirk of LSC 89.1 pointed out to me by a graduate student. Consider the following trivial program:
#include <stdlib.h>
#define N ...
main ()
{ int x[N];
printf (" success\n");
}
When N is defined as 1010 or more, the program runs fine. When N is defined as less than 970, the program runs fine. When N is define between 970 and 1010, the program produces garbage or hangs.
Since x is declared as local to main, it will be placed on the stack. With a default stack space of 4k, it is easy to see why an array size larger than 1000 would max out the run-time stack. What is confusing is why LARGER arrays seem to produce no problems! This example program is a simplification of a more complex program in which the quirk was first noticed. My guess is that a test is made concerning array allocations during compilation -- when an array is larger than stack space, it is moved to s
tatic memory or the default stacksize is increased. (Either that or example programs with large arrays have all been extremely lucky). Some feature of the test fails when the array size is nearly 4k or (int x[970]) to (int x[1010]).
Scott R. Cannon, PhD scott@cannon.cs.usu.edu
Dept. of Computer Science (801) 750-2015
Utah State Univ. FAX (801) 750-3378
Logan, UT. 84322-4205bailey@jacobs.CS.ORST.EDU (Kirk Bailey) (05/17/91)
My guess as to Scott's puzzle: When the array is small enough to fit into the stack everything is fine. When the array is large enough to almost fill the stack the local variables used by the "printf" function cause the stack to overwrite the Transputer reserved memory locations at the bottom of the address space. When the array is larger than the stack the local variables used by "printf" clobber somewhere else (most Transputer hardware vendors leave high order unused address lines uncommitted, this causes the physical address space to be mirrored through out the logical address space...) The solution: make the stack allocation large enough for the program being run! Also remember that many library routines will require stack space also. Allowing 1K bytes of stack per LSC library function invocation is a safe assumption, although many library routines use far less. In general I suggest making the stack MUCH larger than really needed during the program development phase and only worrying about stack size and placement during final program optimization (assuming that optimization is really justified by the application!) Cheers, Kirk Bailey Logical Systems