Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!orstcs!jacobs.CS.ORST.EDU!bailey From: bailey@jacobs.CS.ORST.EDU (Kirk Bailey) Newsgroups: comp.sys.transputer Subject: Re: quirk in LSC Message-ID: Date: 16 May 91 17:34:32 GMT References: <9105161454.AA06109@cannon.cs.usu.edu> Sender: @lynx.CS.ORST.EDU Organization: Oregon State University, Computer Science Dept Lines: 21 Nntp-Posting-Host: jacobs.cs.orst.edu 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