[Libre-soc-bugs] [Bug 495] Add API to PowerISA spec simulation to properly handle [partially] undefined results in tests

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=495

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.