Table lookups - this is pretty definitive

[Dmitry Olshansky]

03-Apr-2014 00:39, Walter Bright пишет:
> On 4/2/2014 12:03 PM, Dmitry Olshansky wrote:
>> SwitchCallStatment:
>>      goto CallExpression;
>>
>> Semantics:
>> Same as that of a function call expression except:
>> a) Can Switch-Call only to a function with the same return type.
>> b) Anything below this statement is unreachable, i.e. treat it as return.
>> c) Stack frame of the current function is overwritten with that of
>> switched-to
>> function. In other words after a switch-call stack looks as if the
>> switched-to
>> function was called instead in the first place.
>>
>> The last point is what modern tail-call optimizations do when one has 2
>> functions that tail-recurse to each other. They overwrite stackframes
>> on such
>> tail calls.
>
> How is this different from simply recognizing "return foo(arg);" as
> being a goto?

If we can alter semantics of
return foo(arg);
to _always_ be a goto, guarantee a jump and reuse of the stack,  then 
I'm all for it.

>> However this only happens with certain optimization switch which IMO
>> makes the
>> thing totally unreliable. In fact I even observed that I could implement
>> threaded-code interpreter by relying on tail-call optimization with
>> LDC, but
>> only when compiling with all optimizations enabled. Unoptimized builds
>> simply
>> blowup stack. This "semantics are tied to optimization" is a situation
>> that I
>> hate about C/C++ and would hope to address in D.
>
> Doesn't seem terribly different than the "force inline" feature discussion.

Yes, it shows the same problem: semantics and optimization are often 
mixed up. In this case however a program would segfault if the relevant 
optimization was not performed, it's not just be many times slower.

-- 
Dmitry Olshansky