Implement opcode completeness test

[marhel]

Devise and implement tests to verify that we implement no more, and no less opcodes for m68k than Musashi, to ensure our opcode handler table is as correct and complete as Musashis.

Perhaps just as simple as running one test on each possible opcode (64K) but could be optimized a lot. Maybe check 64K - our implemented handlers, as those should be verified by other tests, or include "one entry per instruction" to just skim those.

[marhel]

This has been implemented in d7b1fd33. The complete instruction space (64K possible opcodes) are QC-tested (once per opcode). The tests are divided in blocks of 1K tests, and all of them can be run with ./pqc block or ./pqc block19k or even ./pqc block2[4-9] to run through block 24-29. A single block takes something like 20 seconds on my machine, but parallellized can run 10 blocks in 50 seconds, so only a couple of minutes for complete coverage.

[emoon]

Very nice :)

[marhel]

The reason we run just one random test per opcode here is that the completeness test mostly serves to find missing opcode-implementations, such as a forgotten addressing modes, and are not meant to extensively test implementation correctness of a single instruction. The instruction specific QC-tests does that better.

Apart from the two instructions still to be implemented, UNLK and TST, these tests found bad opcode masks for LEA, a few missing addressing modes for MOVE and BTST, and the fact that 16- and 32-bit Bcc overlaps 8-bit Bcc, and since 32-bit Bcc is illegal on the 68000, must be explicitly excluded) (See a949bd3b, 9acc5bb5, a9143f8, 2fe2b1fd)

[emoon]

Cool :) Almost there then. I think you perhaps can just take parts of the stuff I did for UNLK to get the final two implemented then.

[marhel]

Ok, I'll pick stuff out of your unlink.opcode branch then, thanks for helping out!