[Libre-soc-dev] SimdSignal library

[Jacob Lifshay]

On Sat, Oct 2, 2021, 02:50 lkcl <luke.leighton at gmail.com> wrote:

> On Sat, Oct 2, 2021 at 3:18 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Fri, Oct 1, 2021, 11:56 Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >>
> >> sure! adapting the testing code I just wrote to work with
> PartitionedSignal should be relatively easy -- mostly accounting for the
> fact PartitionedSignal can be partitioned more ways since misaligned and
> non-power-of-two-sized lanes are not excluded (even though those lanes
> probably aren't very useful for an actual cpu), as well as changing the
> padding check to always use the no-padding case.
> >
> >
> > Added PartitionedSignalTester:
> >
> https://git.libre-soc.org/?p=ieee754fpu.git;a=commitdiff;h=99b48a366020f8a690452ed08da3117506766345
>
> ok good... except two things:
>
> 1) cesar has already written one: so as not to waste effort (and NLnet
> funds) when he reminded me of that, i asked if you could check and
> work with what he has done, not duplicate effort.
>

To be 100% clear: I do *not* think Cesar's code is worthless, he has been a
great help and I hope he continues to contribute/participate in Libre-SOC.

At the time I wrote that commit, i hadn't read your emails yet, and it
didn't occur to me to use Cesar's work. I had already done the work of
porting the code from simd_signal and I think it is still worth having
committed it. I was out of time, so only had time to send a short message.


> 2) you added type information, after i've asked i think about nine or
> ten times over the past 2 years not to do that, because the resultant
> code is unreadable, longer (more lines), takes up more space, and so
> many other things i'm getting very irritated repeating them.
>

sorry, it was in the original source (simd_signal) i derived the code from
and I forgot to move it.

>
> in attempting to correct them i couldn't even understand what this is
> doing:
>
>         self.reference_output_values = {
>             lane, tuple(
>                 inp.sig[lane.translate_to(layout).as_slice()]
>                 for inp, layout in zip(self.inputs, self.layouts))
>             for lane in self.layouts[0].lanes()
>         }

well, it's actually:
        self.reference_output_values = {
            lane: tuple(
                inp.sig[lane.translate_to(layout).as_slice()]
                for inp, layout in zip(self.inputs, self.layouts))
            for lane in self.layouts[0].lanes()
        }

it constructs a dict mapping lanes to tuples of slices of signals, by
nesting essentially a list-comprehension inside a dict comprehension. each
element of the tuple is a sliced signal, where the slice is
lane.translate_to(layout).as_slice()


>  if i've been using python for 21 years and can't interpret that, it's
> a bad sign.
>
> there's no code comments - at all - so i have absolutely no idea what
> the code is doing.
>

well...the type annotations are part of the documentation...following the
types should get you 90% of the way there. Assuming you're using an IDE
that shows variable types (vim should be able to do that by using pyls or
similar language servers), following the types is quite easy, assuming it
can still see type annotations somewhere.

>
> if i don't know what the code's doing, i can't even make a guess at
> how to fix it.


yup, it needs more docs.

Jacob