Error stack strawman

[Andreas Rossberg]

On 24 February 2016 at 02:01, John Lenz <concavelenz at gmail.com> wrote:

> To be clear I meant, the VM knows *statically* whether to write code for a
> regular call or a tail call and that it is *possible* to do something
> *clever* by inspecting and rewriting the stack.  Specifically, if you can
> inspect the stack for something that is inserted before performing the
> first tail call it is *possible* possible to distinguish.   This is both
> complicated and potentially costly and very likely not worth the effort.
>

A function can only find out whether it is performing the "first" tail call
if it can find out whether it was tail-called itself. So _every_ tail call
would have to inspect the stack to look for the special tail call frame, in
order to decide whether it should push that special frame itself. So yes,
that would make tail calls prohibitively expensive.

/Andreas


On Fri, Feb 19, 2016 at 1:53 AM, Andreas Rossberg <rossberg at google.com>
> wrote:
>
>>
>>
>> On 19 February 2016 at 10:29, Andreas Rossberg <rossberg at google.com>
>> wrote:
>>
>>> On 19 February 2016 at 06:29, John Lenz <concavelenz at gmail.com> wrote:
>>>
>>>> However, at the CPU level, it seems like you would be better pushing an
>>>> return address for a special function that indicated the start of a
>>>> sequence of tail calls.  That way you trade only some
>>>> complexity/performance for tail calls (an inspection of the last entry of
>>>> the call stack) and some stack frame building complexity (to recognize this
>>>> "special" frame).
>>>>
>>>
>>> There is no way of knowing, neither statically nor dynamically, that you
>>> are at "the start of a sequence of tail calls". And doing it for every tail
>>> call would of course defeat tail calls.
>>>
>>
>> Or to put that differently: if there was, then the very problem wouldn't
>> exist. ;)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160224/cc849401/attachment.html>