On Thursday, May 20, 2021, Paul Mackerras &lt;<a href="mailto:paulus@ozlabs.org">paulus@ozlabs.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Writing down for future reference what we discussed on the call:</blockquote><div><br></div><div>good idea</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The spec says, for the update-form floating-point loads and stores<br>
({l,st}f[sd]u{,x}) that if RA=0 the instruction form is invalid.</blockquote><div><br></div><div>arrgh and of course that&#39;s not in the pseudocode, and i&#39;m taking that as &quot;literal gospel&quot; [deliberately, so as to find exactly these issues]</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My recollection is that I did some experiments with POWER9 and worked<br>
out that for update-form loads and stores with RA = 0, it doesn&#39;t<br>
cause an illegal instruction interrupt and it does use the value 0<br>
rather than the contents of R0.  That&#39;s why microwatt has RA_OR_ZERO<br>
in the decode table.</blockquote><div><br></div><div>ok.  so this actually has quite serious implications.  there&#39;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.</div><div><br></div><div>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*.</div><div><br></div><div>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.</div><div><br></div><div>anything else other than these two options, no matter what the spec says is &quot;ok&quot;, is hard-guaranteed to cause huge incompatibility problems.</div><div><br></div><div>i recall mentioning this before: specifications which have interoperability as a primary objective *cannot* leave things as &quot;optionally undefined&quot;.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The 1000 test sequences in the microwatt repo and the sequences<br>
generated by the simple_random program include invalid instruction<br>
forms.  Getting those invalid forms to match P9 behaviour is necessary<br>
for the results to match up - which they do.</blockquote><div><br></div><div>yes i remember, i ran it on the HDL side, with regfile dumps via the DMI interface and got direct interoperability that way :)</div><div><br></div><div>i&#39;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.</div><div><br></div><div>ok thank you for responding, Paul, we have some thinking to do.</div><div><br></div><div>l.</div><div><br></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>