Sujet : Re: stacks are not hard, The joy of FORTRAN-like languages
De : johnl (at) *nospam* taugh.com (John Levine)
Groupes : alt.folklore.computers comp.os.linux.miscDate : 04. Oct 2024, 04:49:53
Autres entêtes
Organisation : Taughannock Networks
Message-ID : <vdnol1$255q$1@gal.iecc.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
According to Peter Flass <
peter_flass@yahoo.com>:
The subroutine calling convention required the calling program
to pass a pointer to a register save area. A recursive routine
would have to allocate a save area in each instance (and, of
course, free it before exiting). If they wanted local variables,
they'd have to allocate and free them as well.
>
Presumably local variables would be allocated together with the save area.
All the assembler code I wrote used GETMAIN/FREEMAIN, then I had a
head-slapping moment a few years ago when someone said “just allocate a big
chunk of memory and allocate save areas from it to eliminate lots of SVCs.”
Of course this only makes sense when your assembler code has lots of
internal calls, not for small stand-alone subroutines.
That's essentially what PL/I did. The save areas and local variables were
allocated from a big chunk of memory, and when it ran out, the subroutine
prolog called an internal PL/I routine to get a new chunk and chain them
together. Read all about it here starting on page 158:
https://bitsavers.org/pdf/ibm/360/pli/C28-6594-4_PL1_F_Programmers_Guide_Nov68.pdfAnd for the PL/I subset on the tiny 360/20, it starts on page 200:
https://bitsavers.org/pdf/ibm/360/model20/C33-6007-1_360-20_PLI_Dec68.pdfI hear that Algol F did GETMAIN/FREEMAIN at every block or procedure
entry and exit. Someone at Princeton hacked it to suballocate from
larger chunks and vastly improved runtime performance.
-- Regards,John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",Please consider the environment before reading this e-mail. https://jl.ly