As mentioned in: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/div/test/test_pipe_caller.py;h=9c4ba3feeceb834cfb87869d0c7d764660e74b64;hb=fe09321a98f193a629d873a8ea055cc72ba949ff#l14 The python simulation of the PowerISA specification needs to grow new API interfaces to allow tests to correctly ignore cases where the PowerISA spec doesn't actually specify which output values are correct. I think the API should track undefined values at the bit level, allowing tests to match the parts of the output that are specified, while knowing to ignore the bits that aren't specified. A relatively easy way to do that is adding a validity mask to SelectableInt and setting `undefined` to have all bits invalid. We can probably assume that all non-bitwise operations can just generate completely undefined results (or just raise an exception) if they encounter partially undefined inputs.
(In reply to Jacob Lifshay from comment #0) > As mentioned in: > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/div/test/ > test_pipe_caller.py;h=9c4ba3feeceb834cfb87869d0c7d764660e74b64; > hb=fe09321a98f193a629d873a8ea055cc72ba949ff#l14 > > The python simulation of the PowerISA specification needs to grow new API > interfaces to allow tests to correctly ignore cases where the PowerISA spec > doesn't actually specify which output values are correct. > > I think the API should track undefined values at the bit level, allowing > tests to match the parts of the output that are specified, while knowing to > ignore the bits that aren't specified. A relatively easy way to do that is > adding a validity mask to SelectableInt and setting `undefined` to have all > bits invalid. We can probably assume that all non-bitwise operations can > just generate completely undefined results (or just raise an exception) if > they encounter partially undefined inputs. this allows the specification maintainers (OpenPOWER Foundation) to create undefined behaviour, the result of which is absolute total chaos and catastrophic failure of the OpenPOWER initiative. one of the reasons that paul mackerras, anton and the team created microwatt is to *specifically* track down areas where the developers of the v3.0B spec had made the mistake of setting "behaviour is undefined" and to work out *full* compatibility with IBM POWER9. anton's "random program generator" was specifically created with this in mind, to probe the behaviour of IBM POWER9 with instructions (and instruction fields) that are not even listed in the spec. v3.0B is currently created "after the fact" - as a semi-afterthought by IBM engineers. this behaviour *has* to change if OpenPOWER is to be successful and the absolute last thing we need to be doing is to "accept" the "undefined" behaviour. bottom line: if the spec says "x <- undefined" it's flat-out wrong, and we need to research and explicitly modify the pseudo-code so that it covers *all* cases - exactly matching POWER9 *without* fail such that the word "undefined" (currently set to zero) can ultiamtely be removed. failure to follow this process will result in us having to do what Ahmdahl did with their clone of the 360: provide *software emulation* of IBM *incorrect* hardware implementation in order to get absolute correct software behaviour without customers having to recompile from source (which in the case of Ahmdahl's customers they were quite right to refuse to do).
ngggggggh diff --git a/openpower/isa/fixedarith.mdwn b/openpower/isa/fixedarith.mdwn index fe3350f..7a03aff 100644 --- a/openpower/isa/fixedarith.mdwn +++ b/openpower/isa/fixedarith.mdwn @@ -444,8 +444,8 @@ Pseudo-code: overflow <- 1 else result <- DIVS(dividend, divisor) - if (result[32:63] = 0) then - RT[32:63] <- result[0:31] + if (result[0:31] = 0) then + RT[32:63] <- result[32:63] RT[0:31] <- undefined[0:31] overflow <- 0 else