Decompiler fuzzing

[MLanghof]

Checking that no code changes when decompiling and then re-compiling a ROM should both help identify issues in either of them and also ensure that they can be used without worries.

I have created a row of tests for this and already eliminated some decompiler bugs. Just opening this PR now so others don't have to redo the work (sorry @SiebelsTim!) and because there's something to discuss. See below.

[MLanghof]

So the tests currently all fail because of the simple fact that the decompiler tends to output push8 #1 when the ROM contains the verbose version of this instruction, which the compiler then collapses into a function call.

This is somewhat unavoidable because the decompiler cannot accurately recreate the source code: Since data and code are not separated in the VM (and programs can modify themselves), it is entirely legal for e.g. a pushf #13.0 in the code (5 bytes) to have the last 2 bytes "executed" (e.g. jumped to). So are they an instruction or are they part of a float constant? The decompiler can't decide that.

(Note: While db8 and friends are the only ways to my knowledge that cause the decompiler to output something else than the compiler was given, we can't just remove those instructions.)

So going back to topic, there will be cases where the decompiler has to chunk the ROM into pieces that do not correspond to the original code. Which means the decompiler can stumble upon a verbose push8 #1 as mentioned above, which it currently can't prevent the compiler from condensing into c_1.

I don't know if we want to introduce an "incompressible" version of the constant pushes. Or if we don't care if compiling decompiled ROM may produce something completely different than the original ROM.

Ideas welcome.

Edit: I now fixed this by outputting db8/dbf statements where necessary, with a comment indicating that it's a verbose push.

[MLanghof]

The decompiler now works reliably!

Decompiling your ROM and then compiling the result should now always return the original ROM.

Bugs fixed:

Decompiler:

• Not obeying to new float literal syntax.
• Negative direction relative pushes were missing an & 0xFF.
• Failing on jumps at pc = 255.
• Not outputting actual relative commands when it meant to do so.
• The pc+1 correction to relative commands (#125) was not applied.
• Floats being output with insufficient precision.

Compiler:

• Relative commands accross RAM ends were not accepted. No reason why they shouldn't be.

[krisives]

This needs rebasing, but we have other problems I suppose.

[MLanghof]

Rebased because of conflicts.