[Libre-soc-dev] [OpenPOWER-HDL-Cores] mfocr and mtocrf v3.0B spec ambiguity

[Paul Mackerras]

On Thu, Aug 27, 2020 at 10:41:55PM +0100, Luke Kenneth Casson Leighton wrote:
> apologies, there is another spec discrepancy between IBM POWER9 behaviour
> and what is listed in the v3.0B spec.
> 
> microwatt's behaviour has been designed to match that of IBM POWER9 by
> running unit tests that test exact correspondance.
> 
> this because anything other than that results in disastrous binary
> incompatibility.
> 
> microwatt analyses bit 20 in the XFX Form and if set will perform a one-hot
> priority pick of FXM (bits 12 to 19).
> 
> if not set then the entire mask is used to select CR registers.
> 
> the specification not only says nothing about bit 20 (it is not listed as
> being used), it states that "preferred" behaviour is permitted.

Bit 20 (IBM bit 11) is shown as "1" in the instruction diagram for
mfocrf and "0" for mfcr.  In other words it's a kind of extended
extended opcode bit for those instructions.

For the case of mfocrf with more than one bit set in FXM, the ISA says
that the result is undefined, and microwatt follows what POWER9 does.

> a specification that can allow ambiguous behaviour *will* result in
> incompatibility.
> 
> can i recommend that the specification be updated to reflect actual IBM
> POWER9 and microwatt behaviour?

I think that's reasonable.  Certainly the language in the mfocrf
description could use some updating, as one paragraph says that if
exactly one bit of FXM is set, then the contents of the remaining bits
of register RT are undefined, and then the next paragraph says those
bits "are set to 0's instead of being undefined as specified above",
which is unnecessarily confusing; the first paragraph should just say
that the remaining bits are set to 0.

> otherwise, applications are guaranteed to break.

Well, only if compilers or assembly language programmers use mfocrf
with more than one bit set in FXM, which would be a perverse thing to
do...

Regards,
Paul.