#6 Incorrect interpretation of sign extended immediate

[ereisch]

i8086arithmetic.c appears to improperly decode instructions that utilize the "s" field (bit 1 of the base opcode). This can be demonstrated with the following operation:

83F89A (cmpw ax,-0x66)

For the "cmp" instruction (and some others, I'm sure), bit 1 of the opcode isn't interpreted as the data direction bit, but rather the "sign extension" bit. In this case, this bit is set, which means the last operand should be signed-extended to 16-bits. i8086AddImmed appears to only check if bit 1 is set, and if so, treats it as an 8-bit immediate, and copies para.b[al+1] into immeddata. In reality, I think this should do a check on bit 7 of para.b[al+1], and if set, should OR the parameter with 0xFF00 before stuffing into immeddata.

The disassembler correctly displays the instruction as having a signed parameter, even though it incorrectly displays it as a "byte"-sized operand:

cmp ax,byte -0x66

I have a fix for this in the one case (in i8086AddImmed), but without an 8086 programmers manual handy, I'm not sure whether there are other locations where this should be added, and how the (now) signed comparison should affect the arithmetic flags over a straight unsigned comparison (if at all).

[ereisch]

More on this: I also think all of the "negative summands" flag setting sections in correctOvCaFlagafterAddSubExtended() are incorrect. From reading this (accepted answer), the "addition" section flags are all being set correctly, but the subtraction (negative "b") flags are not:

+-+ should probably not be setting OF
+-- should probably be setting CF
--+ should probably not be setting CF
--- should probably not be setting OF

That was just a cursory glance, and also assuming that the table in the the accepted answer in the linked posting is correct.