Re: When/why did function calls get cheap?

Jack Crenshaw <jcrens@earthlink.net> wrote (bottom-quoting fixed):
> Peter Seibel wrote:
> > My understanding is that in Olden Times, Real Programmers avoided
> > using lots of small functions because the overhead of a function call
> > was considered high. ...
> [Hardware stacks are very old. The DEC PDP-6, the predecessor to the
> PDP-10 and DEC-20, had them in 1964. ...., It's not
> hard to do stacks on the 360 since it has so many registers, although
> OS/360 and its descendants don't make it as easy as they should. -John]
>
> Short answer from one who watched it happen: It was the stack.
>
> The old IBM mainframes didn't have a stack pointer or other hardware
> to support a call stack. They used register 14, as I recall, as a
> dedicated register pointing to the return address. Sort of a
> one-level stack. If your subroutine called another subroutine, it had
> to save off register 14 in memory first, then restore it after
> returning from the next level down.


R14 was used for return address, and R15 often callee address
(and default savearea) by convention, but not set in hardware.
And it was usual for callee to save caller registers, including R14,
at entry and restore before exit, using SToreMultiple and LoadMultiple.
(Also, S/360 was not the only 'old IBM mainframe. <G>)


....
> AIR, minicomputers were the first to have stack pointers and
> call/return mechanisms in hardware. But what really made it efficient
> was the advent of the microprocessor.
>
> I don't think many people appreciate what great strides Intel made
> when they introduced the 8080. At the time, the notion of a computer
> with built-in support for a 64k stack was unheard of. This made it
> not only possible, but practical, to pass parameters by pushing them
> onto the stack.


The 8080 stack could be anywhere in the 64k address space, but not all
of it, unless you had no other data or code including boot. Which is
obviously pretty unlikely. Only with 286 could you have a full 64KB
for stack (assuming sufficient phyiscal memory, of course).


> Granted, the 8080 instructions for manipulating data on the stack were
> primitive by modern standards, but they were very advanced at the
> time, even compared to minis and mainframes.


8080 did not have SP/offset, or indeed any reg/offset, although
8086/88 did. You had to load a constant to BC or HL, DAD SP, then
indirect. In fact I think using HL was only on Z-80, but that part's
a bit blurry. People usually passed arguments in registers if at all
possible rather than on the stack; CP/M certainly did, and I assume(d)
that's why MS-DOS did and continued to long after x86 made it
unnecessary.


The PDP-10 of about(?) a decade earlier, arguably priced and used more
as a host than a mini, had three(!) types of subroutine call, saving
the return address on a stack of which you could have several if you
wanted using any GPR except maybe 0; in a GPR; or in callee memory
like most(?) earlier DEC architectures. You could also push your own
data on such stacks and access with reg+-offset, anywhere in the 256KW
address space.


The PDP-11 of several years earlier, definitely a mini, had subroutine
call that either pushed return address immediately, using R6 fixed by
hardware but also usable like any GPR to address memory with offset;
or 'staged' in a register (often but not necessarily R5) also giving
you addressibility to caller code/inline data.


I believe 8080 didn't use callee memory because by that time the
advantages of pure, and in particular for micros ROMable, code had
become clear; and using a register would have further stressed an
already scarce and costly resource, so they were basically forced to
stack. I agree Intel 'made great strides' in getting a CPU onto one
chip at all, with its benefits in cost, size, power, and reliability,
but not particulary in stack usage.


And yes, MC68k was (and is) a much nicer architecture;
of course, they had the benefit of 'standing on shoulders'.
--
- David.Thompson 1 now at worldnet.att.net

Return to the comp.compilers page.
Search the comp.compilers archives again.