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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Oct 9 11:46:53 BST 2020

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

On Fri, Oct 9, 2020 at 5:27 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Thu, Oct 8, 2020 at 5:42 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> > or, is that actually what you meant?
> >
> > that undef(x) *returns* x, thus indicating to readers that the value x
> > is "actual POWER9 behaviour but the spec stupidly and dangerously says
> > actually you can do whatever you like, here, no really"
> >
> That's exactly what I meant, except for leaving out the "stupidly and
> dangerously" phrasing.


> > that i *am* happy with however i would prefer that the keyword be left
> > as "undefined" and for pyparser to detect "undefined" and
> > "undefined(x)" and to replace that with an INTERNAL and SPEC INVISIBLE
> > call to "undef"
> Ok, I'll fix that tomorrow, or you can fix it first if you like.

done this morning.

> I
> mostly just picked "undef" as a word that is different than
> "undefined" but means the same thing, so I wouldn't have to add code
> to disambiguate.

done.  stringldst and system were the last ones, i just disabled the
detection code in parser.py

> 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?"

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?


More information about the Libre-soc-dev mailing list