[Libre-soc-dev] bug in microwatt stfsu and stfdu

Luke Kenneth Casson Leighton lkcl at lkcl.net
Thu May 20 01:21:50 BST 2021

On Thursday, May 20, 2021, Paul Mackerras <paulus at ozlabs.org> wrote:

> Writing down for future reference what we discussed on the call:

good idea

> The spec says, for the update-form floating-point loads and stores
> ({l,st}f[sd]u{,x}) that if RA=0 the instruction form is invalid.

arrgh and of course that's not in the pseudocode, and i'm taking that as
"literal gospel" [deliberately, so as to find exactly these issues]

My recollection is that I did some experiments with POWER9 and worked
> out that for update-form loads and stores with RA = 0, it doesn't
> cause an illegal instruction interrupt and it does use the value 0
> rather than the contents of R0.  That's why microwatt has RA_OR_ZERO
> in the decode table.

ok.  so this actually has quite serious implications.  there's no way we or
in fact anybody no matter how large their resources can double-check that
binaries world-wide over the past NN years has not made an assumption that
POWER9 acts this way.

even if one version of gcc for example issues instructions that assume
RA_OR_ZERO work the way that you confirmed they do on IBM POWER9, that
means that there are binaries out there which, if we want to be compatible,
we simply cannot do anything other than what POWER9 does, *regardless of
what the spec states is permissible*.

as Tim pointed out, however, we do have one (and only one other option):
throw an illegal instruction exception.  we can catch it and decide what to
do: hopefully performance will not be trashed as a result.

anything else other than these two options, no matter what the spec says is
"ok", is hard-guaranteed to cause huge incompatibility problems.

i recall mentioning this before: specifications which have interoperability
as a primary objective *cannot* leave things as "optionally undefined".

> The 1000 test sequences in the microwatt repo and the sequences
> generated by the simple_random program include invalid instruction
> forms.  Getting those invalid forms to match P9 behaviour is necessary
> for the results to match up - which they do.

yes i remember, i ran it on the HDL side, with regfile dumps via the DMI
interface and got direct interoperability that way :)

i've not got anywhere near being able to do that with the FP ops, this is
the emulator only.  HDL will be a few months yet.

ok thank you for responding, Paul, we have some thinking to do.


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

More information about the Libre-soc-dev mailing list