should program call stack grow upward or downwards
minor note ... the savearea allocation was the responsibility of the calling program ... but the saving of registers were the responsibility of the called program ... i.e. on program entry, the instruction sequence was typically: STM 14,12,12(13)
50th Anniversary of invention of disk drives 4586
Yeah. Been there, done that. Not really imagining, just remembering. :) In some ways, it was better. For one, you generally got an OS that would boot very very fast, mostly by not providing you with...
i.e. "store multiple" registers 14,15,0,...,12 ... starting at (decimal) 12 offset from location pointed to by register 13.
for more detailed discussion ... i've done a q&d conversion of the old ios3270 green card to html ... and more detailed discussion of call-save-return conventions can be found at:
the called program only needed a new save area if it would it turn call some other program. non-reentrant programs (that called other programs) could allocate a single static savearea. only when you had reentrant programs that also called other programs ... was there an issue regarding dynamic save area allocations.
the original cp67 kernel had a convention that was somewhat more like a stack. it had a contiguous subpool of 100 save areas. all module call-return linkages were via supervisor call. it was the responsibility of the supervisor call routine to allocate-deallocate savearea for the call.
per aside, cp67 and unix can trace somewhat common heritage back to ctss, i.e. cp67 work was done at the science center on the 4th flr of 545 tech sq
50th Anniversary of invention of disk drives 4590
Anne & Lynn Wheeler I don't think they were very popular. Drums were a "compromise" between the high capacity of disk and the high speed of core. Since drums had fixed heads over each...
including some people that had worked on ctss. multics was on the 5th flr of 545 tech sq ... and also included some people that had worked on ctss.
as i was doing various performance and scale-up work ... i made a number of changes to the cp67 calling conventions.
for some number of high-use non-reentrant routines (that didn't call any other modules), i changed the calling sequence from supervisor call to simple "branch and link register" ... and then used a static area for saving registers. for some number of high-use common library routines ... the supervisor call linkage scenario had higher pathlength that the function called ... so the switch to BALR call convention for these routings significantly improved performance.
the other problem found with increasing load ... was that it became more and more frequent that the system would exhaust the pool of 100 save areas (which caused it to abort). i redid the logic so that it could dynamically increase and decrease the pool of save areas ... significantly reducing system failures under heavy load.
there was subsequent generalized subpool enhancement for cp67 kernel dynamic storage Debt Management ... which also significantly contributed to descreasing kernel overhead.
article from that work Analysis of Free-storage Algorithms, B. Margolin et all, IBM Systems Journal v10n4, 283-304, 1971
50th Anniversary of invention of disk drives 4588
At the same time, it's a shame that so many of the very clever algorithms optimized for serial storage seem to have...
and from the citation site:
50th Anniversary of invention of disk drives 4589
360 had fixed head 2303 & 2301 drums (2301 effectively a 2303 but read-write four heads in parallel) and 4mbytes capacity in the era of...
misc. past postings mentioning cp67 kernel generalized subpool work: