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.
