Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!cmcl2!phri!delftcc!sam
From: sam@delftcc.UUCP (Sam Kendall)
Newsgroups: net.lang.c
Subject: Re: Tail recursion optimization
Message-ID: <138@delftcc.UUCP>
Date: Wed, 16-Apr-86 17:14:19 EST
Article-I.D.: delftcc.138
Posted: Wed Apr 16 17:14:19 1986
Date-Received: Fri, 18-Apr-86 20:57:30 EST
References: <2516@utcsri.UUCP> <708@bentley.UUCP> <2122@watmath.UUCP>
Organization: Delft Consulting Corp., New York
Lines: 33
Summary: The compiler must know about setjmp in order to optimize tail recursion; and how to handle nargs

I haven't seen it mentioned yet that if you optimize away a stack frame
which is referred to by a jmp_buf (the setjmp data type), a longjmp
to that stack frame will fail.  Therefore a compiler that wants to
optimize tail recursion must know about setjmp in order to suppress
tail recursion optimization in functions that call setjmp.  This is
compatible with the ANSI draft standard.

A couple of points to answer (square brackets mine):

In article <2122@watmath.UUCP>, atbowler@watmath.UUCP writes:
> There is a problem if you want to support a "nargs" function with [tail
> recursion].
> If an implementation tries stores the nargs value in some fixed position
> in the call sequence then it cannot optimize tail recursion into
> a branch to this or some other function.

If you really want nargs, just optimize tail recursion into a change to
the nargs value, followed by a branch.  What's the problem?

> [I]t is annoying to have to do things like
> "node1(a), node2(a, b), node3(a,b,c)".

You can use varargs here.  You also need an argument list terminator,
so do something like

	#define NIL	((NODE *) NULL)
	/* assuming arguments to node are of type NODE * */
	node(a, NIL)
	node(a, b, c, NIL)

----
Sam Kendall			{ ihnp4 | seismo!cmcl2 }!delftcc!sam
Delft Consulting Corp.		ARPA: delftcc!sam@NYU.ARPA