Add suport for emulating movzx #35
Conversation
|
I think the separation of state/value setting that you just committed is breaking it... I'll update the commit |
|
Sorry, I am moving around some stuff in emulate.c. But this PR (and perhaps following ones?) is straight-forward, no need for you to make it compile after every break. I can just apply it with slight modifications myself. |
|
The first part of this PR (8/16-bit moves) is without test, and adds emulation of a large number of different conversions (for movsx). We do not really have emulator tests yet which check the result of emulation. We could add a debug output mode which only prints the static data -- which should be enough. |
|
My strategy for testing the results of the emulation is writing tests which performs a calculation that depends on the correctness of emulation and stores the result in rax. That way, since all values used in the tests are static, the only generated instruction will be storing the static result value into rax. It would, however, be nice to have a way of performing fine-grained unit testing of the emulation results of instructions. That would simplify the tests somewhat and make it easier to increase coverage. You're right about the missing test cases for the movsx conversions and the missing generator support. I'll look into that. |
|
About the emulator tests: I see, yes, that works. However, it really would be better to directly call something like emulateInstr() - not existing at the moment - , perhaps just on given input values, and checking for the correct output values/flags without having a dependency on instruction decoding are even different operand types... |
|
Yes, I agree |
|
Just committed the 1st part (8/16 bit mov operands) with 8/8, 16/16 test, but tests for the extended |
No description provided.