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

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

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