Stack Frames

[COTTRELL, JAMES]

/*
> >> 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.

While I rarely do this (I did for the Rand editor for the arrow keys,
they had `ESC [ A', & my terminal produced both that & `ESC O A' as well. I
jumped from one switch into the other) I would not expect any penalty
by doing this. I consider the idea of blocks stupid, merely syntactic
sugar. `{' is `then'. `}' is `end'. Functions should be small enuf so
that nested blocks are not needed. But I'm rambling...
 
> 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.  

And I think you underestimate the difficulty. You are not creating a new
stack frame, which is what the original discussion mentioned. Also, are
you referencing your variables relative to the stack pointer, or the
frame pointer? The stack pointer moves around, especially in expressions
like: `{ int q = 3; printf("%d%d%d%d\n",q,q*q,q*q*q,q*q*q*q); }'.

>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.

While all this is possible, the way Doug described is so much simpler,
faster, easier, & offers less surprises. Your compiler must have been
written by a nested block freak.

> 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.

I agree totally. If it's small, who cares. If it's big, use malloc.
The time overhead is the same to adjust the stack pointer by one as
it is to adjust it by one thousand. Unless you have an `add quick'.

> 				Kenneth Almquist
> 				ihnp4!houxm!hropus!ka	(official name)
> 				ihnp4!opus!ka		(shorter path)

	jim		cottrell at nbs
*/
------