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

[lkcl]

On October 24, 2021 10:27:37 AM UTC, lkcl <luke.leighton at gmail.com> wrote:
>i've just added them as TODOs:
>
>https://git.libre-soc.org/?p=ieee754fpu.git;a=commitdiff;h=31610c7eac17e9e5c52e2a53d7cb6d5d744c7b07
>
>and left room for explaining that other functions should be added as
>well... argh, i can see that Value.cast is going to be needed there
>as well, sigh.

not-so-sotto-voice followup:

basically, to pull this off, the entirety of nmigen and its usage has to be converted away from the "global" style (a la python operator.*) to the "OO" style, a la python x.__add__ and now x.__Mux__.

the first "hit" was the 420-line patch to nmigen itself which removed all vestiges of "global" style dependence, whilst making certain to back-support the existing python operator-style API.

[keeping support for the existing API was - is - critically important to ensure that we don't have to do massive global/search/replace "Mux" with "s.Mux" and so on.  this is easy to understand precisely because the API does not change, and because it is identical to a long-established python convention: the operator module]

this easy-to-forward-port patch basically makes all use of nmigen context-aware right back to dsl.Module (a new parameter has been added, _astTypeCastFn, which was the last remaining part of dsl.Module which was critically dependent on global-style).

however although i only considered Signal initially as being a function that needed to call the class Signal/SimdSignal depending on context, with hindsight i should not be surprised that the entire nmigen API (Shape, Signal.like) also has to become context-aware.

that makes SimdScope a pretty damn important class, it becomes literally the gateway entrypoint to the entire HDL.

sigh at some point it may become necessary to create a SimdRecord class.  that'll be fun.

l.