[Libre-soc-bugs] [Bug 731] potential design oversight in Partitioned SimdSignal Cat/Assign/etc lhs/rhs

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=731

--- Comment #22 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #20)

> how so? What can existing code do that SwizzledSimdValue can't (after Cat
> and Slice are implemented in terms of it and it's todos are done)?

it doesn't use PartType.

> I'm justifying that because I reasoned that the existing Cat code was
> insufficient for LHS use, 

because you didn't trust the incremental approach that i described
is essential for projects of this size and complexity.

> and because combining Cat and Slice (and possibly
> Repl) all into one general class greatly simplifies the logic,

but abandons existing work which you resisted doing so i had to do it.
if you had done it when i asked instead of resisting, then you would
have been the one to make the decisions.

instead, because you kept resisting and wanting to design a version 2.0
before version 1.0 had been completed, you didn't help write PartitionedCat
etc. which then forced me into a position of doing it myself.

once they're done, they're done.  those then become the code that needs
to be incrementally morphed.

>  as well as
> generates far more optimal code (a requirement if we want our cpu to
> actually be low-area/low-power when using simd alus;

this is a good justification: it's also a version 2.0 justification.

we are *seriously behind* jacob.  how many times do i have to point
this out.

a version 1.0 is absolutely absolutely critical to moving the ALUs forward
*regardless* of how inefficient version 1.0 is.

please get this through to your understanding that this is urgent,
urgent, urgent.

> I don't want us to have
> to discard all of SimdSignal as waay too inefficient).
> For things like Cat(a[30:50][2:10:2], b, Repl(c[23], 5)):
> SimdSignal will generate 8(!) layers of muxes (on the order of 2-4000
> gates!), whereas SwizzledSimdValue will generate only 1 layer (since that's
> what it always generates) (I'd guess at most 500 gates, for a 64-bit output
> SimdSignal with 4 possible elwid values -- generating a single 4-in 64-bit
> mux).

that's great!  [for version 2.0 and/or for a drop-in replacement along the
way once we have multiple people working on ALU conversions and writing new
ones]

how many times do i have to repeat that this is urgent, urgent, urgent.

discussing this multiple times is actually actively contributing to those
very delays that i am trying to get you to stop creating.

you are *aggravating* the project, not *assisting* the project right now
by denying taking on board this lesson.



> > it is also an optimisation and it goes too far.
> > 
> > we absolutely have to be extremely strict about this and keep to
> > an incremental development strategy at all times.
> > 
> > if that class is to be used it needs to be scheduled as its own
> > incremental update with full unit tests and full functionality and
> > redesigned as a dropin replacement.
> > 
> > given that the existing classes are functional
> 
> Which they're not, Cat doesn't work for nested use on lhs, 

don't need it.

> and doesn't work when the same Cat instance is used both on lhs and rhs,

don't need it.

>  Slice isn't implemented at all.

only because you haven't done what you've been asked to do!


> All of those can be quickly implemented in terms of
> SwizzledSimdValue (I already posted an implementation of Cat previously that
> handles *all* of those requirements by virtue of letting *already
> implemented* SwizzledSimdValue do all the heavy lifting).

this can be done *AFTER* the urgent urgent urgent job of finishing all
of the AST constructs has been

we are holding up *three people* from helping on parallel tasks of
converting ALUs right now.

a "totally crap from your perspective" version 1 would allow unblocking
of that critical path.

*please listen* and help out

you keep not listening and keep fighting this and not learning this extremely
important Project Management lesson.

we are on *critical path*.

please listen.

please do the tasks that are needed to get off of critical path as
quickly as possible.

please listen.

> The above firmly places it into *faster* to working code territory, cuz I
> already wrote basically all the code.

which i have already told you goes *backwards* because it is not compatible
with the existing API and functionality.

which you haven't listened to me about because you've been trying to focus
everything on version 2.0.

please for goodness sake listen.

> Well, luke, you have to realize that not all things can be implemented
> incrementally, and that forcing them to occur incrementally when not suited
> to that will take waay longer and the diffs will not actually make much
> sense.

this is a skill that i am attempting to teach you.  it is absolutely
essential that you learn it for a project of this magnitude and
complexity.

so please.

will you please.

follow the path that i've outlined.

we are running out of time.

we are holding up multiple people and multiple tasks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.