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

[lkcl]

On October 22, 2021 5:28:29 PM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Fri, Oct 22, 2021, 04:05 lkcl <luke.leighton at gmail.com> wrote:
>> also: given the "carrying of context" (PartType), the idea of
>throwing
>> out SimdSignal.ptype and making it a global is *definitely* a
>nonstarter.
>> it was already a non-starter due to being global (which is frowned
>> on in general, in python, so please don't start making design
>assumptions
>> that rely on any globals of any kind, please) but it's just not going
>to
>work.
>
>To be clear, SimdSignal would always access its SimdScope through a
>member
>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 hours ago)

>The SimdScope global is just
>so
>end-user code doesn't have to pass in a SimdScope instance everywhere,
>since that is useless verbosity.

this is extremely bad practice so is a hard "no".

i have already solved it by adding SimdScope.Signal which on every time you write some pseudocode using SimdScope you have missed the significance of "x = s.Signal(...)" where you keep writing "x = SimdSignal(...)"

please read the code changes carefully including the docstring i added to simd_scope.py to understand why the perceived need for a global is entirely gone.


> SimdShape/SimdSignal constructors
>always,
>as their first step, retrieve the current global SimdScope 

i repeat: that's a hard "no" on globals.  their use is not acceptable in python except under exceptional circumstances (singletons, class factories being the main well-known ones)


>Also, do note that SimdScope can explicitly represent the state of
>SimdSignal becoming unvectorized scalar code
>SimdScope(module=..., scalar=True), 

i have already explained why this is not to be implemented.  any code that implements this dangerous and risky behaviour can be removed.

>class SimdScope:
>    ...
>    @property
>    def scalar(self):

you need to catch up with the messages while you were asleep: that's a hard "no" on scalar-like behaviour.  i did explain it already last week, but you seem to have overlooked it and implemented it anyway.

the scalar parameter itself remains but attempts to provide scalar-like behaviour are not only unnecessary, they are dangerous and risky.

>This allows SimdSignal to easily detect if it should act like a scalar:

hard "no" on that one.  i have explained why twice now.

l.