Stack Frames

[Kenneth Almquist]

>> If your C compiler generates additional overhead for local
>> blocks, it is not very good.  Most reasonable implementations
>> reserve enough stack at function entry for the deepest local
>> block nesting within the function, so that there is no
>> run-time action required upon entering a local block. [DAGWYNN]
>
> Not only `not very good' but seemingly impossible. If a separate
> stack frame [were] created, access to arguments would be different
> within the new block. Still doable, but now try jumping in or
> out of the block. Getting Hairy!		[COTTRELL]

There is at least one compiler out there for which does this.  I know
because I got a bug report on vnews concerning a piece of code where
I jumped into the middle of a block.  The rule is that the effect of
jumping into a block containing declarations is machine dependent.  All
other jumps, such as jumping into a block that contains no variable
declarations or jumping out of a block that does, are all legal, just
as in PL/1.

Cottrell overestimates the difficulty of allocating variables declared
in a block when that block is entered.  On a stack based machine, when
you enter a block with declarations, the compiler merely adjusts the
stack pointer to make room for the variables.  When you exit the block,
either by reaching the bottom or by doing a goto out of it, the stack
pointer must be adjusted back.  This is also fairly simple if the com-
piler is prepared to read the entire routine before it starts generating
code (otherwise it wouldn't know which goto's required adjustment to the
stack pointer).  Ideally, the compiler should also adjust the stack
pointer when compiling a goto into a block that contains declarations,
but C does not require this.

The advantage of this approach is that stack space may be saved if
subroutines are called outside the block.  In most code the space
savings won't make much difference.  The disadvantage is the extra time
spent adjusting the stack pointer.  Again this cost is likely to be small,
but my guess is that is the cost of adjusting the stack pointer will
usually outweigh the space savings that it brings, and most compiler
writers appear to agree.  Still, you cannot count on this if you want
to write portable code.
				Kenneth Almquist
				ihnp4!houxm!hropus!ka	(official name)
				ihnp4!opus!ka		(shorter path)