[Valgrind-users] completing opcode coverage

[John R. <jr...@Bi...>]

> ...  a list of unimplemented MMX/SSE/SSE2 opcodes.  About
> 78% are implemented. ...

The explicit list is a good start at completing opcode coverage.

Looking at the list and at the function disInstr() from the source
coregrind/vg_to_ucode.c -r1.120, I must ask:
Why does the code employ copy+paste+edit so extensively, instead of
taking much more advantage of obvious schemas based on the hardware?
To the code of valgrind there is almost no difference between
ORPS and any of {ANDPS, ANDNPS, XORPS}.  Yet ORPS is unimplemented,
and each of the others has its own individual paragraph of code.
All four of them could share the same paragraph by indexing a small
array with the unique opcode byte.  And why not decode that byte
using a 'switch' instead of a few dozen consecutive 'if'?
These are more than just optimization hacks.  Recognizing and
exploiting underlying schemas to ease coding and improve
performance is one of the hallmarks of a good implementation.

Anyway, based on the annotations in the list, I see some groups:
   1) ALU function-only differences: OR/AND/XOR; MIN/MAX; etc.
   2) ...DQ
   3) CVT...
   4) miscellaneous: CLFLUSH, ...
Exploiting such groupings may ease and speed the completion of coverage.
Completing coverage will save implementor and user time in contrast to
the disappointment and aggravation of complaints dribbling in piecemeal.

--