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