F6.7 IDIV - divide exception expected

[tommojphillips]

There are 4 tests in F6.7 where I would expect a divide exception to occur.

idx: 0952 - 0038b4bacfb75535b5da175f619b0812b16d0601
idx: 1085 - de153d1e3812cdb2c9d25272844b4b28a5adc35f
idx: 2653 - dce03c62813266bf0ba50e3325fa3898132cad1f
idx: 4297 - 38a27640b8a9475f75998d2cab801d51eb8bb0b2

[wilkie]

Let's take a look at two of the byte forms you mentioned. There's a case either way.

Test 4297 (38a27640b8a9475f75998d2cab801d51eb8bb0b2):

name: idiv byte [ds:bx+si+3Bh]

initial: {
  regs: {
    ax: 25529,
    bx: 2277,
    cx: 6433,
    dx: 17076,
    cs: 49927,
    ss: 17436,
    ds: 62964,
    es: 64906,
    sp: 65534,
    bp: 1519,
    si: 65535,
    di: 44073,
    ip: 19656,
    flags: 3270
  },
  ram: [
    [ 818488, 246 ],
    [ 818489, 120 ],
    [ 818490, 59 ],
    [ 818491, 244 ],
    [ 818492, 168 ],
    [ 818493, 47 ],
    [ 818494, 51 ],
    [ 818495, 203 ],
    [ 818496, 87 ],
    [ 818497, 167 ],
    [ 1009759, 185 ]
  ]
},
final: { regs: { ax: 14720, ip: 19660, flags: 1046 }, ram: [] },

So, it reads in ram:u8(ds: bx + si + 0x3b) which is the 185 (0xb9) at 1009759. This is -0x71. AX is initial 25529 which is a positive number 0x63B9. There's no exception expected according to the test, but the quotient certainly overflows if you do the actual math. The expected ax is 0x3980, which is a quotient of 0x80 (which is the lowest possible value) and a remainder of 0x39 or 57.

When we compute the result via a particular binary division algorithm, we do actually get a quotient of 0x80 and the expected remainder. This is due to bits getting lost along the way (which happens because the math actually overflows so the algorithm isn't appropriate) and yet the result happens to be 0x80 after restoring the sign. Yuck!!

Test 952 (0038b4bacfb75535b5da175f619b0812b16d0601)

name: idiv byte [ds:si]

initial: {
  regs: {
    ax: 33217,
    bx: 61452,
    cx: 63357,
    dx: 19929,
    cs: 11869,
    ss: 883,
    ds: 39671,
    es: 58277,
    sp: 30191,
    bp: 42618,
    si: 19698,
    di: 34960,
    ip: 64848,
    flags: 198
  },
  ram: [
    [ 254752, 246 ],
    [ 254753, 60 ],
    [ 254754, 244 ],
    [ 254755, 181 ],
    [ 254756, 236 ],
    [ 254757, 175 ],
    [ 254758, 147 ],
    [ 254759, 165 ],
    [ 654434, 124 ]
  ]
},
final: { regs: { ax: 49536, ip: 64851, flags: 2195 }, ram: [] }

Same deal. If you did the actual math, it would overflow, but a binary division algorithm gets the expected result (ax should be 0xC180): 0x80 for the quotient and 0xc3 as the remainder. Again with this 0x80 special case! It seems to just not fire the exception when the quotient happens to get computed as -128, even if that makes no sense or you could tell way beforehand that you should fire the fault. I would suspect this is a very ugly quirk in the division algorithm that cannot properly detect if the -128 is legitimate or coincidental but preferred to allow the wrong answer in a small amount of cases than to change the algorithm?

This is especially ugly if you don't want to compute the output of the binary division just to know if this is the case. But this only happens in the detected overflow case (where you bail out and do the normal case).

It's technically not "wrong", since it feels like a flimsy optimization on the CPU's part, but I would say it is technically not "right" to abide by the tests either. I would personally skip these cases and not worry about honoring this particular tested chip's decision. There's definitely code out there that needs the undocumented carry flag to work for DIV/IDIV, but there's no code out there that's going to require that very particular invalid division arguments fire/ignore #UD or whatever.

Some existing emulators that pass these tests such as granite would compute the binary division result every time and just ignore the overflow status if the quotient were computed as -128. That seems especially overkill. (And at any rate, you only ever have to do any of the microcode emulation in the exception case to pass these tests, you'll never need to in the normal path. So, I would detect overflow, and in that path only do the microcode-level algorithm and maybe bail out if the quotient is -128 and join the hot path where you otherwise just do your native division instead)

Other two tests

Same deal with the other two tests, just with register forms instead. These should result in 0x80 in the quotient and the real CPU inappropriately doesn't fault.

tl;dr

The tests seem to highlight a heinous bug in this particular CPU (would love to know if other revisions do the same thing) that over-corrects for cases where the quotient becomes -128 after correction. This would unlikely to cause a lot of damage in real-life and/or affect compatibility, and it would be just a novelty to emulate in most projects. It might be nice to have a 'soft skip' list that contains tests (like these) that relate to CPU bugs than more deterministic undocumented behavior.