NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/acorn/tech/56

Internet Message Format | 1992-08-17 | 2.8 KB

Path: sparky!uunet!mcsun!sunic!dkuug!diku!torbenm
From: [e-mail] (Torben AEgidius Mogensen)
Newsgroups: comp.sys.acorn.tech
Subject: Re: New Language/Compiler (ideas wanted)
Message-ID: <[e-mail]>
Date: 17 Aug 92 11:58:38 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Department of Computer Science, U of Copenhagen
Lines: 48

[e-mail] (Chris Dollin) writes:

>In article ... [e-mail] (TMOTA) writes:

>   [e-mail] (Torben AEgidius Mogensen) writes:

>   >Afeature I have sorely missed in compilers for C etc. is a cheap
>   >tail-call: if the last thing you do in a procedure or function is to
>   >call a procedure or function, this can be implemented as a goto rather
>   >than a general procedure/function call. Also, the local variables of

>   What do you mean? What if the tail-called function then tries to call
>   another function or (even worse) recurses? This could only work if
>   the tail-called function expected to recieve *exactly* the stack frame
>   that the tail-caller has had set up when it was called.

>Urk? You clean up the stack before you call the tail-called function, of
>course. It's a standard optimisation, at least in the Lisp world. [The only
>objection to it is that it can make debugging harder -- you lose the functions
>that tail-called when you get the stack backtrace.]

>   And remember that Acorn's C compiler (the ARM proc. call std.?) is clever
>   enough to notice when you call a function that does not call another (a
>   leaf function), and does not bother with most of the context-storing
>   operations involved in normal function calls.

>I'm not sure you said what you meant. There's no cleverness involved in calling
>a leaf function (after all, who's to know that it *is* a leaf function?), it's
>just that leaf functions don't need to carry all the baggage of a full function
>call -- it's the code of the leaf that ``does not bother with most of the
>context-storing operations''. [They don't carry the baggage because there's
>very little that can go wrong inside them, so they don't need to record who
>they are in case something does.]

This is basically the old caller-saves/callee-saves controversy:
caller-saves makes tail-call optimization easy, callee-saves makes
leaf-call optimizations easy.

The reason callee-saves is bad for tail calls, is that it can't see if
it is called from a tail position (unless a separate entry point or
parameter specifies this). The reason caller saves is bad for leaf
call optimization is that things are already saved, so you can't avoid
doing so.

Both of these problems can be partially solved by using a mixture of
caller saves and callee saves strategies.

    Torben Mogensen ([e-mail])