🚀 go-pugleaf

>Not wanting to make rash statements, I retested it.  I'm right.

SunOS's PCC-based compiler for the 68K does the same for the "case"
statement you gave; however, if I added one more arm to the "switch",
with a "case" value of 3, it generated an indexed jump.

In the worst case, for the if/then/elseif/then...  version (i.e., the
value is the last value against which you compare - assuming the value
is within range) of the 3-arm "switch", the indexed jump is better on a
68K.  In the best case (i.e., the value is the first value against which
you compare), the indexed jump is *worse* on a 68K (you do one
comparison and one successful conditional jump).  If the value is the
one in the middle, the indexed jump is *still* worse.

The numbers may be different for an 80*86, but there may still be a
turn-over point; below some number of comparisions, the
if/then/elseif/then... chain may be better, and above that number an
indexed jump may be better.  If so, then if the number of cases in the
"switch" statement is small enough, assuming a reasonably even
distribution of the values "switch"ed on generating an
if/then/elseif/then... chain may be the right thing.

However, if you're switching amongst, say, 64 different values, it's
probably the wrong thing.  Given that, I hope Intel's C compiler doesn't
*always* generate an if/then/elseif/then... chain for a "switch"
statement; if the switch statement is dense and has sufficiently many
arms, I would hope it would generate an indexed jump (I find it
difficult to imagine that an indexed jump would *never* be better).

Try a few more arms; if you make it up to, say, 32 arms, and it *still*
generates an if/then/elseif/then... chain, the compiler is probably
being dumb (but check the cycle counts anyway, just for fun...).  If
there is an inflection point, check the cycle counts, etc. to see
whether an if/then/elseif/then... chain makes sense for a number of
arms below the inflection point.  If so, perhaps the PL/M compiler is
the wrong one....