[libre-riscv-dev] buffered pipeline

[Luke Kenneth Casson Leighton]

ok, so, jacob, this is difficult for me to say but it is also
important.  i'm under financial pressure so there's not a lot of
wiggle-room to do too much experimentation, although doing so as a
learning process is, i appreciate, extremely important.

i've noticed that you sometimes don't respond to my comments, which
means that from that point onwards, you continue working without
consensus and agreement.  this has happened more than once, which is
making me extremely nervous, given the increased financial pressure
i'm under.

i do not mind if you have a justification for continuing in a
particular direction, however it's *important that you express it and
we agree it*.  please, speak up!  if you have a reason, it's really
really important to express it and to convince me (all of us) of the
merits of the idea.

for example, i am still waiting for you to come back to me about the
assessment that a barrel processor is totally unsuitable for anything
other than a low-clock-rate I/O processor, particularly that the lack
of multi-issue capability needs to be compensated for with a
*four*-fold increase in either SMP concurrency or SIMD capacity over
the presently-agreed design, both of which have very strong
disadvantages.

i'm also waiting for you to come up with a proposal that incorporates
all of the types of data arrangements in the pipeline API - not just
the one (Record), and for a response to the other comments that i
made.

instead, you went ahead with an extremely well-engineered and
well-designed pipeline, which has let you explore many of the features
of python that even i didn't know existed, despite using python for
nearly 19 years.

the problem is: it is completely over-engineered [and limited in
capability].... *and i've created duplicate code that's more
flexible*.

we *really haven't time* and i don't have the financial resources to
explore too many things without keeping each other "in check".  yes
i'm counting on you (and everyone else) to make sure that what i'm
doing - no, what *all* of us are doing - is sane and on track.

each of us bring something different to the table.  me, i have nearly
28 years of software engineering experience (good god that's a hell of
a long time), which gives me an ability to think and plan ahead from
potential paths, assessing the time taken for each, and aggressively
pruning options that would take too long.

i also have a strong pathological attitude towards "not invented here"
syndrome.  i've written code in eight days that took a *team* of
*three people* over *six months* to write an equivalent, because i
chose to pick and join code that came from python-gobject, netscape,
webkit and other wildly disparate projects.

the other team spent months duplicating code that did 95% of the job
and would only have needed 5% adaptation.

these kinds of decisions come from experience, from necessity, and
from having an extremely ambitious goal that's *not* about the "what"
- it's about the *why*.  although i've wanted to do a processor for
nearly 30 years, it wasn't until i had a reason *why* i wanted to do
one that i actually went ahead and decided to commit to one.

so please, please understand: talking about what we're going to do,
and getting consensus, is much *much* more important than actually
writing code.

haven't quite covered everything, i know i've missed things out...
getting too long... hope you understand.

l.