Computed gotos on Reddit
Don Clugston
dac at nospam.com
Wed Jul 25 01:09:48 PDT 2012
On 25/07/12 09:55, Dmitry Olshansky wrote:
> On 25-Jul-12 11:51, Don Clugston wrote:
>> On 25/07/12 09:37, Walter Bright wrote:
>>> On 7/24/2012 11:46 PM, Dmitry Olshansky wrote:
>>>> It's pc => address because one can first preprocess all of byte code
>>>> doing
>>>> opcode => address rewrites. But you can't do it unless taking address
>>>> of labels
>>>> is possible.
>>>
>>> All right, that's the piece that was missing.
>>>
>>> I suppose it is possible for the compiler to recognize that the
>>> opcode=>address array is invariant, and optimize it out, but that would
>>> be a novel optimization. I don't know how hard it would be.
>>>
>>>
>>> > Done: http://d.puremagic.com/issues/show_bug.cgi?id=8431
>>>
>>> Thanks!
>>
>> Another interesting optimization with "final switch" would be if each
>> case has about the same code length.
>>
>> final switch(x) {
>> case C1: ...
>> case C2: ...
>> case C3: ...
>> case C4: ...
>> }
>> then if &(case c2) - &(case C1) == &(case C3) - &(case C2)
>>
>> change it to
>> goto (&case C1) + x *( &(case c2) - &(case C1) );
>>
>> so that there is no lookup table, just a multiply.
>
> Could be interesting if some other simple progressions could be
> hardcoded, if say branches are be sorted by length.
Ooh, that's an interesting idea too.
> Also modern CPU seem
> to be exceptionally fast at skipping NOPs so a bit of padding won't hurt.
And an unconditional branch takes no time (only one 1 uop) on modern
CPUs too.
More information about the Digitalmars-d
mailing list