[Libre-soc-bugs] [Bug 324] create POWER9 DIV pipeline
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Fri Jun 19 16:04:06 BST 2020
--- Comment #25 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #24)
> (In reply to Luke Kenneth Casson Leighton from comment #23)
> > (In reply to Jacob Lifshay from comment #21)
> > > I was thinking SelectableInt and other custom classes would implement the
> > > trunc_div and rtrunc_div member functions, which is the trunc_div version of
> > > __sub__ and __rsub__. Similarly for trunc_rem and rtrunc_rem.
right. ok. i am with you now. this will have to happen later... but *not* as
part *of* SelectableInt, but as a module (or class) that has the operations.
in this way we will implement SimpleV at that level.... *not* in SelectableInt
basically we are missing a class named "Power9CompliantSelectableInt"
which later will become:
> > the problem is that if we do that, SelectableInt behaves unpredictably.
> > SelectableInt is designed not to be a "POWER9 compliant integer arithmetic"
> > class, it's designed to be a direct one-to-one and onto map of the behaviour
> > of the python *int* class - just one that happens to have a bitlength
> > associated
> > with it.
> > thus we genuinely expect SelectableInt's floordiv and truncdiv behaviour to
> > be exactly that of int, and consequently if in any code anywhere we need to
> > perform a div (or mod), we expect it to actually work.
> they behave the same as int even if the trunc_div and trunc_rem member
> functions are overridden with a custom implementation that calculates the
> same results.
i'm not understanding you, sorry. trunc_div and trunc_rem are standalone
functions not members so cannot be overridden.
the parser now specifically identifies the div and mod circumstances and calls
them directly, *bypassing* the % and / operator overloads entirely.
this is something we have to do anyway for all operators (in order to be able
to do dynamic SIMD backend for SimpleV)
> The member functions are designed to work for classes like Signal or other
> special classes that are sufficiently unlike int that they needs to be
> manually implemented.
> the trunc_div free function calls the member functions if they exist -- just
> like abs(a) calls a.__abs__()
> there's no reason trunc_div should or would match __floor_div__ -- they're
> different operations.
yes sorry i meant rem
> I was thinking about implementing trunc_div as a monkey-patched member
> function of int, but was not sure that was a good idea or if int can even be
it can't, and changing int behaviour would cause havoc on a global scale. we
would need to create yet another int wrapper class and use it everywhere.
this would be terribly slow (and unnecessary)
> > here's the thing: although you may not have been aware of it, trunc_div and
> > trunc_rem are *behaving as expected* despite the fact that you wrote them
> > assuming that they would take python ints as arguments!
> that's mostly expected.
> > and that's *exactly* why SelectableInt.__floordiv__ and
> > SelectableInt.__truncdiv__
> > should not implement POWER9 div behaviour :)
> __floor_div__ is a flooring-division operator, of course it shouldn't be
> truncating division, that's what trunc_div is for :)
sorry i meant rem.
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs