[Libre-soc-dev] my current plan regarding simdsignal
luke.leighton at gmail.com
Fri Oct 22 19:59:07 BST 2021
On October 22, 2021 5:46:06 PM UTC, lkcl
>>To be clear, SimdSignal would always access its SimdScope through a
>>variable, specifically: self.shape.scope.
>simply passing in the SimdScope as an argument to all SimdSignals, via
>the new function SimdScope.Signal, is sufficient.
>modifying SimdShape after-the-fact to add in scope? mmm... yyeah,
>honestly it doesn't matter how it gets there.
>(this will make sense when you read the comments / commits of a few
as things stand, it is unnecessary to have SimdShape have a scope member variable, but if you would prefer that it have one please *do not* make it take the scope parameter in its constructor.
instead, use the exact same trick as i deployed by adding SimdScope.Signal(*args, **kwargs) calling
and returning SimdSignal(mask=self, *args, **kwargs)
or, have a function SimdShape.set_scope()
both of which when you think through, you will realise have limitations (that are solved by not having scope be a member of SimdShape at all).
limitation 1: SimdShapes (unnecessarily) absolutely and inappropriately have to be in a Context (with SimdScope).
limitation 2: intrusive modification of SimdShape by calling set_scope then prevents and prohibits its use elsewhere.
plus, as explained in the comments now in layout(), scope is scope and has nothing to do with shape which is shape.
*only the layout function* combines the Context (scope) with the shape, to create the required information that SimdSignal needs.
it therefore makes sense to keep scope entirely separate from shape, for multiple reasons.
More information about the Libre-soc-dev