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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sun Oct 24 21:50:00 BST 2021


--- 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)


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.

More information about the libre-soc-bugs mailing list