[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 #27 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #26)

> The standalone functions tries to call the member functions if they exist,
> this is to emulate python's behavior where a - b calls a.__sub__(b) or
> b.__rsub__(a).
> 
> So, if I had a custom class:
> 
> class MyClass:
>     def trunc_div(self, d):
>         print("trunc_div:", self, "/", d)
>         return 0
>     def rtrunc_div(self, n):
>         print("rtrunc_div:", n, "/", self)
>         return 0
>     def __repr__(self):
>         return "MyClass"
> 
> trunc_div(MyClass(), 123)
> trunc_div(MyClass(), MyClass())
> trunc_div(456, MyClass())
> 
> outputs:
> trunc_div: MyClass / 123
> trunc_div: MyClass / MyClass
> rtrunc_div: 456 / MyClass

only the functions in the operator module work this way.  the above is not
how python works.  or, if it is, it's literally the first time i've heard
about it in 20 years!

>>> trunc_div(MyClass(), 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'trunc_div' is not defined

yep, it's not how python works.  you have to call MyClass().trunc_div(123)
or define a trunc_div (global, non-class) function:

def truncdiv(a, b):
    if isinstance(a, MyClass):
         return a.truncdiv(b)
    if isinstance(b, MyClass):
         return b.reverse_truncdiv(a)
    raise Exception()


operator.truncdiv on the other hand is *specifically* written to do what you
are expecting (except calling __truncdiv__, where operator.add calls __add__,
etc. etc. for each function operator.{xxx} it calls __xxx__ )

so the function operator.add goes something like:

def add(a, b):
   if hasattr(a, "__add__"):
       return a.__add__(b)
   else:
       return b.__radd__(a)

or close to it.  it *might* do some checking to see which is the largest
(most accurate) class.  in order this would be something like int, float,
complex
where float is capable of representing all ints, and complex is capable of
representing all floats.

therefore, we are *bypassing* that with the functions that are now in
soc/decoder/helpers.py

really we should not in any way be using the operator overloads  __add__ etc.
at all at the POWER9 level.

at the POWER9 level they should all be done in the format MyClass and then
have the parser.py generate AST which calls those functions directly as
2-argument functions.

you can see this is done here for "!=" already, in parser.py:

def make_ne_compare(arg):
    (left, right) = arg
    return ast.Call(ast.Name("ne", ast.Load()), (left, right), [])


this will create python code "ne(RA, 0)" when it sees "RA != 0" in the
pseudocode.

*every* operator needs to be like this.

if you want to make it "clearer", it should be called "POWER9_ne",
and "POWER9_trunc_div" etc. however the reason we've not done this is
because it makes the auto-generated code pretty much unreadable :)

the places to be compliant with POWER9 are in those functions "POWER9_ne".
*not* in SelectableInt.  SelectableInt is very specifically designed to
be that "int override" class that you mentioned (the monkey-patch one).
*not* as a POWER9-compatible class.

yes we need that POWER9-compatible class, but not right now.  helpers.ne,
helpers.trunc_div, helpers.trunc_rem "do that job" and the plan is to
move them into a MyClass-style-formatted object... but not right now.

when we add SimpleV it will be absolutely essential to add that MyClass-like
object, because that MyClass-like object will be told what the SIMD
partitioning
currently is, what VL currently is, and it will also have to be passed the
full Register File.

but... not right now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.