[Libre-soc-dev] my current plan regarding simdsignal

[Jacob Lifshay]

On Sat, Oct 23, 2021, 21:48 lkcl <luke.leighton at gmail.com> wrote:

>
>
> On October 24, 2021 4:12:08 AM UTC, Jacob Lifshay <
> programmerjake at gmail.com> wrote:
>
> >In this particular case, I think it's fine, since the way it is used is
> >such that it's much more similar to how Python's super() function
> >works:
> >If code is inside the `with SimdScope(...)`, then it will use that
> >SimdScope. If it's outside, then it will raise an error.
>
> jacob: please, no.  globals are not fine.  i have made that absolutely
> clear.
>
> wby are you ignoring what i am saying and continuing to justify something
> that someone with 20 years experience in.python has said "no" to?  i don't
> understand.
>

Because it doesn't work like your thinking, from my perspective you just
heard "global" and decided it was bad without understanding it.

>
> >
> >I originally got this idea from Rust's async design, where async
> >functions
> >can get access to the state necessary to schedule the async function to
> >be
> >woken up again after I/O by accessing a only-set-within-a-scope
> >thread-local variable.
>
> we are not using async in python it is too new and advanced.
>

I never said we need async, it's a technique used to *implement* async's
machinery in Rust, other than that, it's totally unrelated to async.

>
> >I can change it to also use a thread-local (needed if code is
> >multithreaded
> >rather than just multiprocess like usual for Python (multiprocess is
> >standard for tests)).
>
> no, please stop.  this introduces complex low-level features of python
> that other programmers from a hardware background will not understand.
>

Hmm, I think it'll be quite easy to understand how it's used, all it does
is returns the innermost `with SimdScope` in the call stack, and errors if
there are none.

nmigen guessing signal names by parsing Python's IR is waay more complex
imho.

>
> the last thing we need is more complexity.
>
> >The idea is that each Elaboratable class that we refactor to use
> >SimdSignal
> >will basically always wrap its elaborate() (and maybe __init__ too)
> >function's body in a `with SimdScope`, such that it's always pretty
> >obvious
> >where the scope comes from.
>

I meant wrapping in this sense:
# exactly how code would look in our .py files
class MyModule(Elaboratable):
    ...
    def elaborate(self, platform):
        m = Module()
        with SimdScope(self, m):
            # normal body
            a = SimdSignal(5)
            b = SimdSignal(5)
            m.d.comb += a.eq(b)
            return m

*not* in the sense of overloading. The external API of MyModule is not
modified.

That said, since you don't like globals, if we *instead* do:
class SimdScope:
    def __init__(self, ...):
        ...
        self.Signal = partial(SimdSignal, scope=self) # we need
partialclass...
        self.Shape = partial(SimdShape, scope=self)
        self.Signal_like = partial(SimdSignal.like, scope=self)
        ...

That could work, though it wouldn't be as easy to read...

Jacob