That was an interesting bug. In my Hyperstone JIT for MAME, I was getting a mismatch with the interpreter results on one particular emulated ADDC (add with carry) opcode.
Näytä tämä ketju
-
MAME uses an IR called "UML" - Universal Machine Language - and you write functions that contain a series of macros, such as UML_ADD(block,dst,src1,src2), UML_MOV(block,dst,src), UML_ROLINS(block,dst,src,shift,mask), and so on.
Näytä tämä ketju
Turns out I had a bug in my implementation such that the correct sum would be calculated, but the carry-out flag would be unset. Now, in the interpreter implementation, the src, dst, and carry flag are cast to uint64_t and summed, then bit 32 is used to determine carry-out.
-
-
As it happened, in the IR/UML representation, I was summing the source register and carry bit by using a 32-bit UML_ADD, then summing it with the destination register using the 64-bit UML_DADD.
Näytä tämä ketju -
The end result, and it's obvious in retrospect, is that the carry-out bit would be erroneously unset if and *only* if we had a carry-in, and the source register was 0xFFFFFFFF. Because FFFFFFFF+1 sums to 0 when using 32 bits. Use UML_DADD instead of UML_ADD, bug fixed. Oops.
Näytä tämä ketju
Keskustelun loppu
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.