From: lwinson@bbs.cpcn.com (lwin) Newsgroups: alt.folklore.computers Subject: Re: IBM/370 - no stack? Date: 31 Aug 2000 22:51:01 GMT Organization: The PACSIBM SIG BBS Lines: 9 Message-ID: <8omngl$rgi@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.uni-stuttgart.de!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.gtei.net!news-xfer.newsread.com!bad-news.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root Xref: chonsp.franklin.ch alt.folklore.computers:62822 > Is it true that the IBM/370 didn't have a stack as we know it from today's > hardware architectures, i.e. the programmer had to make his own stack by > reserving memory and using two variables as stack pointer and base pointer? > At least my assembly programming teacher said so, and he did a lot of > programming on a IBM/370-155, until they got a Philips P2000 in May 1982. I believe "stack" is now available on S/390 as a semi-priviledged instruction, but not available on earlier machines. ###### Message-ID: <39AEF45E.893D2E3A@thinkage.ca> From: "Alan T. Bowler" Organization: Thinkage Ltd. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: IBM/370 - no stack? References: <8ombba$b9s53$1@ID-37382.news.cis.dfn.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 41 Date: Thu, 31 Aug 2000 20:12:14 -0400 NNTP-Posting-Host: 192.102.11.4 X-Trace: nnrp1.uunet.ca 967767136 192.102.11.4 (Thu, 31 Aug 2000 20:12:16 EDT) NNTP-Posting-Date: Thu, 31 Aug 2000 20:12:16 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.datacomm.ch!newsmaster-01.atnet.at!newsmaster-03.atnet.at!atnet.at!newsrouter.chello.at!newsfeed01.sul.t-online.de!newsfeed00.sul.t-online.de!t-online.de!colt.net!newspeer.clara.net!news.clara.net!newsfeed.icl.net!netnews.com!newshub.northeast.verio.net!verio!sunqbc.risq.qc.ca!news.uunet.ca!nnrp1.uunet.ca.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:62837 Andreas Krennmair wrote: > > Is it true that the IBM/370 didn't have a stack as we know it from today's > hardware architectures, i.e. the programmer had to make his own stack by > reserving memory and using two variables as stack pointer and base pointer? > At least my assembly programming teacher said so, and he did a lot of > programming on a IBM/370-155, until they got a Philips P2000 in May 1982. There is no "stack" built into the /360 hardware. However, a "stack" is essentially a software concept, and that can be implemented in any number of ways depending on the application. Indeed a program may well use several different techniques on different "stack" data structures. It is common in language implementations to have a single stack of call frame data used to hold return addresses, arguments and local "auto" variables.** Although there are architectures that have hardware support of such, this is by no means necessary. Numerous techniques have been used on the systems without such a hardware bias. Indeed, some of these seem much cleaner and more efficient than what was done on systems where the hardware brings preconceived idea of how a stack should be implemented. We once looked seriously at the "right" call/frame stack for a machine that was in the /360 architecture family. It was not from IBM, but the designers had copied essentially all the normal /360 instructions, and then added some stack instructions, including a "call" based loosely on the the VAX call. In the end we couldn't find a use for the new stack stuff, since a design using the standard /360 instructions was shorter and required 1 less dedicated register. ** Although it is common that return addresses, arguments and autos live together in a single stack there is no absolute requirement for such, and there have been successful implementations where these are physically separated into different structures. The portability group at Waterloo used to work put a lot of effort into chosing the stack/call/return design when moving their compilers to a new hardware architecture. They almost always found something that worked much better than what the hardware documentation suggested for how to do a function call. ###### Newsgroups: alt.folklore.computers References: <8ombba$b9s53$1@ID-37382.news.cis.dfn.de> <8omf07$dik$1@flood.weeg.uiowa.edu> From: jata@aepiax.net (Julian Thomas) Subject: Re: IBM/370 - no stack? Message-ID: <39af0794$4$wg$mr2ice@news.epix.net> X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v2.19zk/19zk Lines: 23 Date: Fri, 01 Sep 2000 01:34:43 GMT NNTP-Posting-Host: 199.224.125.61 X-Complaints-To: abuse@epix.net X-Trace: news1.epix.net 967772083 199.224.125.61 (Thu, 31 Aug 2000 21:34:43 EDT) NNTP-Posting-Date: Thu, 31 Aug 2000 21:34:43 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!209.249.123.233.MISMATCH!xfer10.netnews.com!netnews.com!newspeer.monmouth.com!news-xfer.epix.net!news1.epix.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:62920 In <8omf07$dik$1@flood.weeg.uiowa.edu>, on 08/31/00 at 08:25 PM, jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) said: >Stack based architectures were introduced around 1960 by Burroughs, and >most of the new architectures introduced in the 1970's had dedicated >stack pointer registers. The IBM 360 family, dating as it does from the >1960's, has no dedicated stack pointer register. A stack based architecture was under serious consideration for 360 but was dropped by sometime in early 1962. -- Julian Thomas: jt . epix @ net http://home.epix.net/~jt remove letter a for email (or switch . and @) In the beautiful Finger Lakes Wine Country of New York State! Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org -- -- Computers make very fast, very accurate mistakes. ###### From: glass2@glass2.lexington.ibm.com Newsgroups: alt.folklore.computers Subject: Re: IBM/370 - no stack? Date: 1 Sep 2000 14:42:57 GMT Organization: IBM Austin Lines: 33 Message-ID: <8oof9h$d28$1@ausnews.austin.ibm.com> References: <8omngl$rgi@netaxs.com> Reply-To: wa4qal@vnet.ibm.com NNTP-Posting-Host: glass2.cv.lexington.ibm.com X-Newsreader: IBM NewsReader/2 2.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!news.uni-stuttgart.de!uni-erlangen.de!newsfeeds.belnet.be!news.belnet.be!news.tele.dk!63.211.125.72!cyclone2.usenetserver.com!news-out.usenetserver.com!newsfeed.skycache.com!Cidera!typhoon.sonic.net!uunet!sac.uu.net!fox.almaden.ibm.com!news2atm.raleigh.ibm.com!ausnews.austin.ibm.com!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:63342 In <8omngl$rgi@netaxs.com>, lwinson@bbs.cpcn.com (lwin) writes: >> Is it true that the IBM/370 didn't have a stack as we know it from today's >> hardware architectures, i.e. the programmer had to make his own stack by >> reserving memory and using two variables as stack pointer and base pointer? >> At least my assembly programming teacher said so, and he did a lot of >> programming on a IBM/370-155, until they got a Philips P2000 in May 1982. > >I believe "stack" is now available on S/390 as a semi-priviledged >instruction, but not available on earlier machines. > The hardware stack exists on the IBM ESA/370 and ESA/390 machines. It functions with the Branch And stacK instruction (BAKR) to save the general purpose registers, the access registers, and some other state information. The Program Call instruction (PC) can also use the hardware stack, which makes it very convenient when doing address space switches. The Program Return (PR) instruction unstacks the information and returns to the caller. There's also the ability to examine and even modify portions of a stack entry using the ESTA, EREG, and MSTA instructions. It's interesting to note that the hardware stack is not designed to be directly examinable by a user state program. The stack is not based on a general purpose register (e.g., no user stack pointer), thus, there is no architected way for a user to get access to the hardware stack (e.g., it may be hidden from the user in system storage). It especially important that a general user not be able to get write access to the storage that contains the stack since state information is contained on the stack which should not be changable by a general user. Dave P.S. Standard Disclaimer: I work for them, but I don't speak for them. ###### From: gah@ugcs.caltech.edu (glen herrmannsfeldt) Newsgroups: alt.folklore.computers Subject: Re: IBM/370 - no stack? Date: 1 Sep 2000 19:53:41 GMT Organization: California Institute of Technology, Pasadena Lines: 24 Message-ID: <8op1g5$649@gap.cco.caltech.edu> References: <8omngl$rgi@netaxs.com> NNTP-Posting-Host: seniti.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #1 (NOV) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!informatik.tu-muenchen.de!news.csl-gmbh.net!newsfeed.dpn.de!news-out3.f.gtn.com!news-in2.f.gtn.com!newsfeed.germany.net!news.vas-net.net!diablo.theplanet.net!newsfeed.icl.net!news.maxwell.syr.edu!newsswitch.lcs.mit.edu!uchinews!nntp-server.caltech.edu!gah Xref: chonsp.franklin.ch alt.folklore.computers:62883 lwinson@bbs.cpcn.com (lwin) writes: >> Is it true that the IBM/370 didn't have a stack as we know it from today's >> hardware architectures, i.e. the programmer had to make his own stack by >> reserving memory and using two variables as stack pointer and base pointer? >> At least my assembly programming teacher said so, and he did a lot of >> programming on a IBM/370-155, until they got a Philips P2000 in May 1982. >I believe "stack" is now available on S/390 as a semi-priviledged >instruction, but not available on earlier machines. OS/360 calling convention is linked list based, not stack based. Programs, in general, do not make a stack using registers for stack pointer and base pointer. Static allocations use a static allocated save area, for reasonably fast linkage. Dynamic allocation for languages allowing recursion must dynamically allocate the register save area. All the local variables can be allocated at the same time. It is a doubly linked list. If a program abends it can be traced in both directions to find out how it got there. It might be that Linux/390 uses a stack in registers like that, or the S/390 stack instructions. -- glen ###### Newsgroups: alt.folklore.computers From: jsaum@world.std.com (Jim Saum) Subject: Re: IBM/370 - no stack? Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Sat, 2 Sep 2000 03:09:51 GMT References: <8omngl$rgi@netaxs.com> <8op1g5$649@gap.cco.caltech.edu> NNTP-Posting-Host: ppp0b178.std.com Organization: Software Tool & Die X-Newsreader: MT-NewsWatcher 2.4.4 Lines: 23 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news.tesion.net!news.belwue.de!informatik.tu-muenchen.de!news.csl-gmbh.net!blackbush.xlink.net!news0.de.colt.net!colt.net!newspeer1.nac.net!netnews.com!howland.erols.net!portc.blue.aol.com.MISMATCH!portc01.blue.aol.com!feed.newsreader.com!uunet!ffx.uu.net!world!jsaum Xref: chonsp.franklin.ch alt.folklore.computers:62817 In article <8op1g5$649@gap.cco.caltech.edu>, gah@ugcs.caltech.edu (glen herrmannsfeldt) wrote: >OS/360 calling convention is linked list based, not stack based. >Programs, in general, do not make a stack using registers for stack >pointer and base pointer. Static allocations use a static allocated >save area, for reasonably fast linkage. Dynamic allocation for >languages allowing recursion must dynamically allocate the register >save area. All the local variables can be allocated at the same time. >It is a doubly linked list. If a program abends it can be traced in >both directions to find out how it got there. If by dynamic allocation you mean GETMAIN (mainframe equivalent of malloc) that's a performance killer. To avoid that, IBM's S/3x0 PL/I (which allows recursion) since 1971 has been allocating stack frames on a preallocated stack, so they don't have to do GETMAINs unless the stack fills up. If it does, they GETMAIN another piece of memory, so the whole logical stack becomes a linked set of non-contiguous segments. But in the normal case, where the preallocated stack is big enough for the deepest call scenario, the stack-handling avoids GETMAINs and so performs well. - Jim Saum