* [COFF] [TUHS] Unix quix [not found] <20200122184244.14CBB18C083@mercury.lcs.mit.edu> @ 2020-01-23 5:27 ` peter 2020-01-23 14:08 ` clemc 2020-01-24 1:18 ` krewat 0 siblings, 2 replies; 6+ messages in thread From: peter @ 2020-01-23 5:27 UTC (permalink / raw) => coff since it's non-Unix On 2020-Jan-22 13:42:44 -0500, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote: >Pretty interesting machine, if you study its instruction set, BTW; with no >stack, subroutines are 'interesting'. "no stack" was fairly standard amongst early computers. Note the the IBM S/360 doesn't have a stack.. The usual approach to subroutines was to use some boilerplate as part of the "call" or function prologue that stashed a return address in a known location (storing it in the word before the function entry or patching the "return" branch were common aproaches). Of course this made recursion "hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at least of that vintage) normally don't support recursion for that reason. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/49fbaae1/attachment.sig> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [COFF] [TUHS] Unix quix 2020-01-23 5:27 ` [COFF] [TUHS] Unix quix peter @ 2020-01-23 14:08 ` clemc 2020-01-23 14:31 ` clemc 2020-01-24 1:18 ` krewat 1 sibling, 1 reply; 6+ messages in thread From: clemc @ 2020-01-23 14:08 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3888 bytes --] FWIW: System 360 uses what was called the 'push down save area' as part of the function calling convention. Each routine declared and creates local storage for the registers. Being reentrant was certainly possible and many languages such as the Algol and APL families were. It's funny since S/360 was the first architecture I knew deeply (*i.e.* got paid to program), and working on support for York/APL at the time (and began learning the Univac 1100 too), I just thought this was natural until I began to learn about other processors ISA's like the PDP-11 family that had an SP. I remember, thinking -- this is so cool. But as you said, originally early Fortran and Cobol didn't require same. The typical calling conventions was something like this was pretty standard for the S/360: WORKAREA DSECT , Reentrant work area (stack like function) DS 18F Save area FIELD1 DS F Some variable FIELD2 DS F Another variable WORKLEN EQU *-WORKAREA Length of reentrant work area SUBRTN1 RSECT , HLASM will perform reentrant checking STM R14,R12,12(R13) Save registers at entry LR R12,R15 Set code base register USING SUBRTN1,R12 Establish code addressability LGHI R0,WORKLEN Get length of reentrant work area STORAGE OBTAIN, Obtain reentrant work area X LENGTH=(0) ..Length is in R0 ST R1,8(,R13) Forward chain in prev save area ST R13,4(,R1) Backward chain in next save area L R14,20(,R13) Get R1 at entry (parameters) LR R13,R1 Set up new save area/reentrant workarea USING WORKAREA,R13 Establish work area addressability LM R2,R3,0(R14) Get addresses of parameters STM R2,R3,FIELD1 Save parameter addresses for later … *** Subroutine Logic goes here … LR R1,R13 Address to be released L R13,4(,R13) Address of prior save area LGHI R0,WORKLEN Length of storage to release STORAGE RELEASE, Release reentrant work area X ADDRESS=(1), ..Address in R1 X LENGTH=(0) ..Length in R0 LM R14,R12,12(R13) Restore registers OI 15(R13),X'01' This bit on means this save area is inactive BR R14 Return to caller On Thu, Jan 23, 2020 at 12:47 AM Peter Jeremy <peter at rulingia.com> wrote: > => coff since it's non-Unix > > On 2020-Jan-22 13:42:44 -0500, Noel Chiappa <jnc at mercury.lcs.mit.edu> > wrote: > >Pretty interesting machine, if you study its instruction set, BTW; with no > >stack, subroutines are 'interesting'. > > "no stack" was fairly standard amongst early computers. Note the the IBM > S/360 doesn't have a stack.. > > The usual approach to subroutines was to use some boilerplate as part of > the > "call" or function prologue that stashed a return address in a known > location (storing it in the word before the function entry or patching the > "return" branch were common aproaches). Of course this made recursion > "hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at > least of that vintage) normally don't support recursion for that reason. > > -- > Peter Jeremy > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/24bc73a9/attachment.html> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [COFF] [TUHS] Unix quix 2020-01-23 14:08 ` clemc @ 2020-01-23 14:31 ` clemc 2020-01-23 15:51 ` doug 0 siblings, 1 reply; 6+ messages in thread From: clemc @ 2020-01-23 14:31 UTC (permalink / raw) BTW: Not to bring up a new rat hole/new argument, but rather remind people of one of the arguments of the day. Because of SP or no SP style of calling, in those days the question came out language design of how the stack or register call area was maintained: Was it/should it be the responsibility of the calling routine or the called subroutine. Things like Fortran's entry statement and other non-local goto's, co-routines/setjmp/longjmp added fuel to the fire in the argument. As a language designer/implementor at the time, someone like Steve Johnson and Doug McIlroy were undoubtedly mixed up in the argument and had opinions. I was certainly too inexperienced then to understand what the fight was about. But I do remember the fight and how the issues were taught/discussed at CMU when I was a student. I admit I was quickly sucked into C's way of handling things, as it seemed simple/clear/understandable to me, but not being a language person I probably did not (maybe still do not) value some the arguments for the other side. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/2f617b8b/attachment.html> ^ permalink raw reply [flat|nested] 6+ messages in thread
* [COFF] [TUHS] Unix quix 2020-01-23 14:31 ` clemc @ 2020-01-23 15:51 ` doug 2020-01-25 0:09 ` bakul 0 siblings, 1 reply; 6+ messages in thread From: doug @ 2020-01-23 15:51 UTC (permalink / raw) Clem wrote, " the question came out language design of how the stack or register call area was maintained: Was it/should it be the responsibility of the calling routine or the called subroutine. Things like Fortran's entry statement and other non-local goto's, co-routines/setjmp/longjmp added fuel to the fire in the argument." I don't remember much prospective discussion of the subject, but lots of retrospective discussion of techniques that didn't quite work, going right back to Lisp's A-list and the ensuing "funarg problem". The first PL/I out of Hursley got it wrong, too, but they were able to correct it before the bad way became ingrained. In C, which had no need for closures (thunks), efficiency was the main concern in choice of stack protocol. The only delicate situation, longjump, was sidestepped by doing it via library rather than language. Doug ^ permalink raw reply [flat|nested] 6+ messages in thread
* [COFF] [TUHS] Unix quix 2020-01-23 15:51 ` doug @ 2020-01-25 0:09 ` bakul 0 siblings, 0 replies; 6+ messages in thread From: bakul @ 2020-01-25 0:09 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2569 bytes --] I read that thunks came about as an implementation of call by name for Algol. They were basically argument-less closures. Where as a general closure may accept args as well as refer to values in its environment (including those in its lexically enclosing function). I believe at one point gcc used (argument-less) thunks when it added support for nested functions so as to continue using a single ptr as a function argument. A proper closure representation needs a pair (a fun ptr & a ptr to env). The code for all this was stored on the stack & the thunk address actually pointed to this stacked code. I guess that had to be abandoned when storing code on stack was found to be a huge security hole (all because of C’s lax type system & stacks growing down to smaller addresses). Nicklaus Wirth carefully limited the scope of functional arguments in Pascal so as to avoid the “funarg problem” and GC. I think at least by 1975 (when I first studied software) it was clear how to implement “reentrant” functions; It is just that not everyone was convinced of the value of it. Even modern RISC processors don’t actually provide any support for stacks and it is just their “calling convention” that designates a specific GPR to be a stack ptr! No one questions the value of subroutines (even though the register to memory access ratio is soooo much worse now!) but closures and GC are still not so well accepted. On Jan 24, 2020, at 2:07 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote: > > Clem wrote, " the question came out language design of how the > stack or register call area was maintained: Was it/should it be the > responsibility of the calling routine or the called subroutine. Things > like Fortran's entry statement and other non-local goto's, > co-routines/setjmp/longjmp added fuel to the fire in the argument." > > I don't remember much prospective discussion of the subject, but > lots of retrospective discussion of techniques that didn't > quite work, going right back to Lisp's A-list and the ensuing > "funarg problem". The first PL/I out of Hursley got it wrong, too, > but they were able to correct it before the bad way became > ingrained. In C, which had no need for closures (thunks), > efficiency was the main concern in choice of stack protocol. > The only delicate situation, longjump, was sidestepped by > doing it via library rather than language. > > Doug > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff ^ permalink raw reply [flat|nested] 6+ messages in thread
* [COFF] [TUHS] Unix quix 2020-01-23 5:27 ` [COFF] [TUHS] Unix quix peter 2020-01-23 14:08 ` clemc @ 2020-01-24 1:18 ` krewat 1 sibling, 0 replies; 6+ messages in thread From: krewat @ 2020-01-24 1:18 UTC (permalink / raw) On 1/23/2020 12:27 AM, Peter Jeremy wrote: > "no stack" was fairly standard amongst early computers. Note the the IBM > S/360 doesn't have a stack.. You can make a stack out of anything ;) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-25 0:09 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200122184244.14CBB18C083@mercury.lcs.mit.edu> 2020-01-23 5:27 ` [COFF] [TUHS] Unix quix peter 2020-01-23 14:08 ` clemc 2020-01-23 14:31 ` clemc 2020-01-23 15:51 ` doug 2020-01-25 0:09 ` bakul 2020-01-24 1:18 ` krewat
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).