At a high-level these changes add M68040 floating point disassembly (not lifting) support. This doesn't add support for every floating point instruction, but just the instructions contained in my target binaries.
Support for disassembling the 'cinv' and 'pflush' instructions was also added.
Unfortunately, the changes are more intrusive than I would have liked. To be able to share the existing logic in 'decode_effective_address()' with the floating point logic, I had to modify its API to take a size in bytes. But on the positive side that code can now be shared (and not duplicated).
I also updated the IL methods of the new floating point operand classes, but it is not tested. It won't be needed until proper support for lifting of the floating point instructions is added. Every attempt has been made, though, to test the new disassembly logic. The accuracy of the disassembly was verified using GCC's m68k cross-toolchain.
A few other considerations I'd like to point out:
These changes were only tested using M68040 binaries. I did not regression test the other architecture variants
I did not test the changes for strict Python 2 compatibility
If/when the plug-in changes are accepted, should consider updating 'plugin.json' as required
At a high-level these changes add M68040 floating point disassembly (not lifting) support. This doesn't add support for every floating point instruction, but just the instructions contained in my target binaries.
Support for disassembling the 'cinv' and 'pflush' instructions was also added.
Unfortunately, the changes are more intrusive than I would have liked. To be able to share the existing logic in 'decode_effective_address()' with the floating point logic, I had to modify its API to take a size in bytes. But on the positive side that code can now be shared (and not duplicated).
I also updated the IL methods of the new floating point operand classes, but it is not tested. It won't be needed until proper support for lifting of the floating point instructions is added. Every attempt has been made, though, to test the new disassembly logic. The accuracy of the disassembly was verified using GCC's m68k cross-toolchain.
A few other considerations I'd like to point out: