Error stack strawman

Isiah Meadows isiahmeadows at gmail.com
Sun Feb 21 03:21:44 UTC 2016


Would it be possible to just define functions with an offset of exactly N
bits before, with tail calls having a separate entry point than regular
calls? Tail calls are already determined statically by spec, so you could
add/subtract N bits to the code you generate for a function call in
optimized code. And the offset could push a boolean to the stack with argc,
etc., saying "this was called via tail call". When this function returns,
tail call or not, this hidden boolean would be popped off.

This flag would be read during stack unwinding, and you could then
add/subtract the offset if it's a tall call to get the real address of the
function, and then do whatever.

As for interpreters, a single boolean flag can still be used. But that
optimization would be a little more difficult.

(Yes, I saw that John Lenz suggested similar, but I'm not suggesting trying
to detect this purely at runtime. That's the point of tail calls. I'm
instead suggesting the entry point be different by a static offset, which
*can* be determined statically.)
On Fri, Feb 19, 2016, 04:54 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. ;)
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160221/48ec1d50/attachment.html>


More information about the es-discuss mailing list