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

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

[Luke Kenneth Casson Leighton]

continuing on this same subject, we have progress on part-resolving the
overflow on divw* and have moved on to divuw*

this is where another spanner in the pseudocode works was discovered.

divw* text (including divwe) says that the integers shall be treated as
signed.

divuw* text says unsigned.

unfortunately the actual behaviour of the divide operator "/" is
*different* for certain identical values.

here is the implementation of a signed trunc div:

x = abs(n)
y = abs(d)
result = y FLOORDIV x
if sign(n) == sign(d) return result
return -result

which works perfectly well for unsigned input as long as the top bit of
either n or d is zero.

the bottom line is that to properly represent the operations in the
pseudocode, a signed div operator needs to be introduced.

(likewise for mod *and mul*)

without these operators the implementor - every implementor - is forced to
read the words rather than rely on the accuracy of the pseudocode.

as we have seen in at least one instance (the sail power implementation
which was derived directly from the IBM XML variant of the spec using a
code generator) that simply does not happen because people trust the
pseudocode to be unambiguous.

unfortunately with there being no discernment between div-signed operator
or div-unsigned, mistakes are being made.

there is actually precedent for postfixing "u" on operators in the spec,
and after some thought that is what i would advocate in this case:

* /u to discern div-unsigned from / for div-signed
* likewise for multiply
* likewise for mod.

more when i am happy with the quantity of unit tests covering a large
enough range of values on all operations.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev