benson@phantom.ksr.com (Benson Margulies) (12/16/87)
What machines have Unix stacks that grow up rather than down? Has anyone any war stories of porting an application across a stack direction boundary and having it break due to pointer magnitude comparisons or other difficulties? Benson I. Margulies Kendall Square Research Corp. harvard!ksr!benson ksr!benson@harvard.harvard.edu
rob@philabs.Philips.Com (Rob Robertson) (12/18/87)
In article <205@ksr.UUCP> benson@ksr.UUCP () writes: >What machines have Unix stacks that grow up rather than down? the at&t 3b series
hmc@hwee.UUCP (Hugh Conner) (12/18/87)
In article <205@ksr.UUCP> benson@ksr.UUCP () writes: >What machines have Unix stacks that grow up rather than down? > Concurrent Computer Corp. (ex Perkin-Elmer) changed the direction of the stack between their V7 implementation and the Sys V version. Unfortunately I can't remember which one went up and which down. This gave severe problems when I tried to port the Berkeley Pascal interpreter which had a lot of assembler code stuff for manipulating arguments on the stack. In the end I gave up. -- + "Who are all these people in my office anyway?" + + + + Hugh M. Conner hmc@ee.hw.ac.uk +
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (12/22/87)
In article <205@ksr.UUCP> benson@ksr.UUCP writes: >Has anyone any war stories of porting an application across a stack >direction boundary and having it break due to pointer magnitude comparisons >or other difficulties? How about vi? When we were porting Unix to a processor not only had a stack that grew upward, but also had the stack in low memory (well, below the heap), we found, after a long series of seemingly random problems, that the routine to free memory attempted to see if the address of the item to be freed was above or below one of its parameters and only called free() if the address was lower. Therefore, in our case, it tried to free() things on the stack and never freed things on the heap. Obviously, eventually, things got trashed in strange ways and it would punt. This was some time ago; the problem may have since been fixed. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
ron@topaz.rutgers.edu (Ron Natalie) (12/22/87)
Worse yet, the HEP used to malloc "stack" into a linked list.
john@uw-nsr.UUCP (John Sambrook) (12/28/87)
In article <205@ksr.UUCP> benson@ksr.UUCP () writes: >What machines have Unix stacks that grow up rather than down? The stacks on the Data General MV series computers grow towards high memory. >Has anyone any war stories of porting an application across a stack >direction boundary and having it break due to pointer magnitude comparisons >or other difficulties? When I ported XLISP I had to modify one statement due to the direction of stack growth, but finding and repairing the problem didn't take too long, maybe half an hour. The use of the varargs facility would have prevented this problem, if memory serves. I've found a couple of `dangling reference' bugs in code ported to the DG system. Some of these bugs have been difficult to find in that you don't expect them because the code works on many systems. Pathalias 1.6 had such a bug that apparently only manifested itself on the DG MV and the ATT 3B series of computers. Note that these types of problems are darn near impossible to find unless you have access to a fairly wide range of different machines to port your code to. >Benson I. Margulies Kendall Square Research Corp. >harvard!ksr!benson ksr!benson@harvard.harvard.edu -- John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386