[Libre-soc-bugs] [Bug 736] SimdSignal's integration with nmigen needs to handle first args not being SimdSignals

[bugzilla-daemon at libre-soc.org]

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

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
"Note If the right operand’s type is a subclass of the left operand’s type and
that subclass provides a different implementation of the reflected method for
the operation, this method will be called before the left operand’s
non-reflected method. This behavior allows subclasses to override their
ancestors’ operations."

ngghhh.... yyeah that makes sense.  i always wondered how that worked.
does it apply to Cat() though? i really don't know.

i made an arbitrary choice: however... whatever the choice is,
they are all going to be "bad"

s = SimdSignal(...)
Cat(Const(...), s)

or

Cat(Const(...), s)

these are both "valid", so which one should be acceptable?  which one
prohibited, the other allowed?

i believe my thinking here was (without documenting it), that *all*
of Cat()'s arguments are expected to be SimdSignals.  or, at least,
if the first one is, everything else follows.

a more advanced version would detect the type of non-SimdSignal
instances within the list and upcast them.

however what i didn't want to do was have that logic "pollute"
nmigen.ast.Cat with things that are SimdSignal-specific.

it's a tricky one, i'm not sure what the best solution is here,
and was going for "wait and see what emerges down the line" when
we have a lot more info about how this works in practice.

one obvious workaround: a SimdScope.Cat().  used as:

   with SimdScope(....) as s:
      .... s.Cat(...)

however it is... hmmm... it would be the first major ast Operator
that fell into this usage pattern, it has implications.

really don't know, here.

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