quirk in LSC

Thread View: comp.sys.transputer

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Scott Cannon Thu, 16 May 1991 14:54

#1665

Author: Scott Cannon
Date: Thu, 16 May 1991 14:54

24 lines
1726 bytes

  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-4205

Re: quirk in LSC

#1668

Author: Kirk Bailey
Date: Thu, 16 May 1991 17:34

21 lines
1736 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads