[Libre-soc-dev] All div pipe tests pass

[Jacob Lifshay]

On Fri, Oct 9, 2020, 03:47 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Fri, Oct 9, 2020 at 5:27 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> > I also still need to reintroduce all the "undefined"s into the mul
> > instructions spec since someone else removed them to get the tests to
> > pass. That will take a whole lot more work since I'll have to compare
> > the pseudo-code with the spec pdf to find all the "undefined"s we
> > lost.
>
> ehn?  err... mulhwu
>
>     prod[0:63] <- MULS((RA)[32:63], (RB)[32:63])
>     RT[32:63] <- prod[0:31]
>     RT[0:31] <- prod[0:31]
>
> but spec is
>
> prod0:63 ï ¦ (RA)32:63 ï‚´ (RB)32:63
> RT32:63 ï ¦ prod0:31
> RT0:31 ï ¦ undefined
>
> ahhh i know what happened.  this is a *perfect* example of what i
> mean.  i removed the word "undefined"... *because microwatt confirmed
> that POWER9 returns double-32-bit product*.
>
> this one's actually an extremely serious violation of "good spec
> behaviour" because unlike the div-overflow path which is extremely
> uncommon, this one is the kind of thing that applications will very
> specifically end up using "because well POWER9 does it, what are you
> complaining about?"
>

well, the modsw instruction has similar behavior -- sign-extending the
result in all cases when the spec leaves the top 32-bits undefined. IIRC
the div overflow cases all return 0 on power9.

>
> so yes that should become - termporarily:
>
>     prod[0:63] <- MULS((RA)[32:63], (RB)[32:63])
>     RT[32:63] <- prod[0:31]
>     RT[0:31] <- undefined(prod[0:31])
>
> i leave that with you?
>

yeah, I'll go through and clean those up later today.

Jacob