[libre-riscv-dev] spec ambiguity divwe - divwue v3.0B / v3.1B

[Luke Kenneth Casson Leighton]

https://bugs.libre-soc.org/show_bug.cgi?id=323#c6

apologies, another follow-up: regarding the use of "undefined" in the 3.0B
spec.

as was shown historically with the Amdahl 370 clone, full interoperability
even with ostensible "undefined" behaviour is often critical to a
business's decision-making on whether to purchase a product.

in the case of the Amdahl 370 they had to provide a software patch to
emulate *incorrect* IEEE754 behaviour of the 370 because customers had
already written software that worked around or otherwise critically relied
on the IBM 370 hardware, and those customers were in no way prepared to go
to further expense to modify that software.

based on this historical lesson it is of some concern to us that we not
make the same mistake, and therefore refine the answers given to precisely
match the behaviour of IBM POWER9, *not* match "strict minimalist 3.0B
specification requirements".

it turns out that microwatt is likewise following this strategy,
particularly for mul and div.  mulhwu for example returns the 32 LSBs
duplicated *twice* because that is exactly what IBM POWER9 does.

in our case however the software simulator is based on the spec pseudocode,
and therefore to match that exact same behaviour *we need to modify the
pseudocode*

https://libre-soc.org/openpower/isa/fixedarith/

XO-Form

   - mulhw RT,RA,RB (Rc=0)
   - mulhw. RT,RA,RB (Rc=1)

Pseudo-code:

prod[0:63] <- MULS((RA)[32:63], (RB)[32:63])
RT[32:63] <- prod[0:31]
RT[0:31] <- prod[0:31]  was undefined

this divergence therefore has me slightly concerned.  originally the
intention was to stick exactly to the 3.0B spec mandated pseudocode however
we know the consequences of that [Amdahl example].

my concern is that by modifying and publishing these changes, when other
implementors in future learn of these modifications, and decide that they
also want full binary interoperability with POWER9 for the exact same
reasons, and also want to save time and development costs just like we did,
then instead of using IBM's *official* specification pseudocode (which,
remember, does *not* match the exact behaviour of POWER9, the de-facto
leading implementation), they use the *unofficial* version from *our*
website, instead.

now, if we had not created an autogenerator (a parser and codegenerator)
thus making the unofficial pseudocode hard to use (i.e. useless to all
intents and purposes) this would not really be an issue.

however the time that has been saved by doing so is vast, and it has been
extremely successful, so it is not an option to go backwards by
hand-editing and hand-maintaining the autogenerated output.

nor either would it be reasonable to request (or expect voluntarily) that a
charitably funded software libre project take down code or documentation
published under full audit and transparency requirements of their funding
body (NLNet) as part of NLNet's "Privacy and Enhanced Trust" Programme (
https://nlnet.nl/PET)

i really have no idea what to suggest here.  i am simply laying out the
consequences of the decision to use "undefined", and explaining why we have
to make modifications.

personally in 30 years experience i have found "undefined" to be an issue
in any spec (generally) where it is used and where interoperability is
expected, however that is my personal experience, and there may be
extremely good historical reasons why it is used, in this case, that i am
not aware of.

apologies that this is quite long.

i leave it with you for consideration when time permits, pending the
POWER10 release.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68