[Libre-soc-bugs] [Bug 324] create POWER9 DIV pipeline

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=324

--- 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
itself.

basically we are missing a class named "Power9CompliantSelectableInt"

which later will become:
SimpleVAwarePower9IshSelectableInt

> > 
> > 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
> monkey-patched.

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.