jim@felix.UUCP (02/09/87)
Although stacks do grow down on: DEC PDP-11 DEC VAX-11 Zilog Z-80 Zilog Z-8000 Intel 8080, 8085 MOS Technology 6502 Motorola 6800 Motorola 68000 NSC 320xx they do grow up on some machines Burroughs B-5x00 Burroughs B-6x00 Burroughs B-7x00 Basic/Four 8000 and some machines do not include any particular support for either direction IBM S/360 Having done a great deal of compiler and system code for the Basic/Four 8000 I found no particular disadvantage in having the stack grow up, in fact, on this thoroughly big-endian machine, it was most pleasant to have "up" mean "towards higher addresses". It also made the microcode/hardware for checking segment overflows simpler since everything only grew at the higher-addressed end. Jim Gilbert FileNet Corporation ...hplabs!felix!jim
mangoe@mimsy.UUCP (02/10/87)
Jim Gilbert writes: >Although stacks do grow down on: [Long list of Machines] >they do grow up on some machines [much shorter list of machines] >and some machines do not include any particular support for >either direction > IBM S/360 "Of course, some people go both ways" Sperry (nee Univac) 1100 series (and other sperry-oids) This makes the people who want to put the stack at one end of the D-bank and the heap at the other REAL happy. C. Wingate
meissner@dg_rtp.UUCP (02/19/87)
In article <5356@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes: > Jim Gilbert writes: > > >Although stacks do grow down on: > [Long list of Machines] > > >they do grow up on some machines > [much shorter list of machines] While we are at it, the Data General Eclipse (16-bit) and MV/Eclipse (32-bit) machines grow their stacks upward as well. This causes two problems in dealing with UNIX on the MV/Eclipses. First is all of the programs that don't use varargs, but still deal with variable argument lists. Second is that the sbrk area must grow upwards. This means you can't in general do the trick of going the stack down and the heap (sbrk) up. If the user does not do a sbrk, but does call malloc, we sbrk the address space, and grow the heap down & the stack up. If the user does call sbrk/brk directly, we reserve a chunk of memory for his/her sbrk-ing, and use the rest as before. There are also options for fixing the size of the stack and/or heap, as well as changing how much memory is reserved for sbrk. -- Michael Meissner, Data General Uucp: ...mcnc!rti-sel!dg_rtp!meissner It is 11pm, do you know what your sendmail and uucico are doing?