[Libre-soc-dev] [OpenPOWER-HDL-Cores] mulhw / mulhwu in microwatt updates SO
paulus at ozlabs.org
Fri Aug 28 08:31:42 BST 2020
On Thu, Aug 27, 2020 at 04:39:21PM +0100, Luke Kenneth Casson Leighton wrote:
> in section v3.0B p73 it says that mulhw, mulhw. and hwu do not have an
> overflow version. CR0 is also intended to be undefined in bits 0:2 in
> 64-bit mode. nothing is mentioned about SO however we might
> reasonably assume that because there is no OE version of mulhw/mulhwu,
> it must be ignored.
What's the "it" in that last sentence?
The ISA shows bit 11 (IBM bit 21) of mulhw and mulhwu as a reserved
field, whereas that bit is the OE bit for mullw and other
instructions. So according to ISA Book 1 section 1.3.3, which says
"Reserved fields in instructions are ignored by the processor", we
should ignore the OE field for mulhw/mulhwu, and we do (and that is in
fact what POWER9 does also).
> wark-wark, fail.
> instruction 1035c in 1.bin:
> 1035c: 97 2c c1 7f .long 0x7fc12c97
> fail again by this command:
> $ powerpc64le-linux-gnu-objdump -D -b binary -m powerpc:common64 -z
> /home/lkcl/src/libresoc/microwatt/tests/1.bin > 1.dump
Yes, objdump refuses to interpret instructions with non-zero values in
> manual decode of 0x7fc12c97:
> major 31
> minor 75
> Oe 1
> rt 30
> ra 1
> rb 5
> Rc 1
> it's "mulhw." but actually it's not, it's "mulhwo." because both OE=1
> *and* Rc=1 which is an instruction that doesn't exist in v3.0B. (so
> why is it in microwatt unit test 1.bin, and where did that unit test
> come from?)
I believe it was produced by Anton's simple_random program.
> put simply: if we "obey" the spec, XER gets corrupted. microwatt is
How does XER get corrupted? mulhw/mulhwu with bit 11 set to 1 should
behave the same as with bit 11 set to 0, i.e., it won't update XER[SO]
or XER[OV] -- and that is how both microwatt and POWER9 behave, and it
is in conformance with Book I section 1.3.3.
> also not "obeying" the spec, and this is cause for some concern /
> alarm, because, strictly speaking, we are violating the OpenPOWER EULA
> by not following - to the letter - the v3.0B specification.
The compliance requirements in the licence are considerably more
relaxed for soft cores than for hard cores, fortunately, otherwise
open-source development of a soft core wouldn't be possible.
> some... clarity on this would be greatly appreciated. are we
> permitted to violate the v3.0B spec (and the OpenPOWER EULA) on the
> basis that if we don't we will end up fragmenting interoperability
> because IBM's POWER9 implementation does something *different* from
> what the v3.0B spec says?
You haven't convinced me that POWER9 does something different from
More information about the Libre-soc-dev