🚀 go-pugleaf

In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:
>	p(a,b,c) { x(a); y(b); z(c); }
>
>In the above procedure, we may discard the current stack frame (or reg
>window in Sparc) before calling z.  We then replace the call z
>instruction by a jump instruction.
>
>It is a sad thing to notice that such a nice optimization is not
>implemented in languages other than Prolog and on RISC architectures.

As has been noted, LISP-like languages are major consumers of tail
recursion technology.

In article <1993Jan2.144518.20826@walter.bellcore.com> mo@gizmo.bellcore.com (Michael O'Dell) writes:
: There are a number of challenges to exploiting the technique 
: in C compilers (having to do with exception handling, setjmp/longjmp,
: etc).

I figure stack management is the toughest part.  the "caller cleans the
stack" calling convention used by many compilers (to make variadic
functions easier) makes it impossible to optimize the last call in a
function like

	f(a) { return g(a, 2); }

because f's caller will clean only one word from the stack, whereas
g will leave two words of garbage on the stack when it exits.

And pointers really make things confusing.  If you gave anybody a pointer
to a local variable, you cannot optimize the last call.  Consider,
for example,

	f(a) { int b; g(&b); return h(a); }

You can't clean f's stack frame before calling h(), because g() and h()
might've been written like this:

	int *scary;
	g(p) int *p; { scary = p; *scary = 2; }
	h(a) { return *scary + a; }

We learn once again that the tremendous flexibility of C's pointers
proves an obstacle to optimization.  (As if we didn't know this already.)
--
Raymond (not a compiler writer) Chen