[Libre-soc-dev] daily kan-ban update 10nov2020

[Jacob Lifshay]

On Thu, Nov 12, 2020, 03:37 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Thu, Nov 12, 2020 at 8:46 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > Sorry, I don't think it's possible (at my rate of coding at least) to
> > get something working that could generate those markdown tables in
> > Python, C++, or Rust. I'd estimate at least 2-3 days.
>
> the actual table-format/printing?  each row is one line of code:
>     return ' | '.join(d) + "|"
>

I used about 150 lines of rust for markdown support since I included proper
text escaping as well as a trait allowing substitution of which table
output format is used.

I also later added html and vcd output and an adaptor for transposing the
tables using another 500loc or so.

>
> so you must mean the creation of the data going into the tables.  and
> that is why i said *don't* go overboard by trying to actually
> "compute" the actual data: *ONLY* output *TIMING* information.  *NOT*
> make it a "full hardware-level pipeline simulator".
>

I was referring to outputting the timing information. that requires
tracking which registers are used in which instruction and tracking
dependencies. that all requires the 2-5kloc I mentioned earlier.

if the amount of code that you are thinking of writing for this task
> is more than 250 lines as a first implementation *it's completely and
> utterly the wrong approach*.
>

So, what approach would you have used? I can't think of a way to do that in
250 lines (excluding cheating by having 1500 character lines or similar).

but you did not listen to what i was saying and wanted to develop a
> full hardware-level pipeline simulator, and to do it in rust wasm.
>
>
> > > what you've done is *ignore* the questions, and are developing
> > > something that hasn't been discussed or evaluated.
> >
> > Sorry, I was under the impression that the plan was to build a program
> > for generating markdown tables, then we could both play around with it
>
> which implies *not in c++ or rust* as i explained multiple times and
> you did not respond, acknowledge, or take into account.
>

I understand why you don't want the actual code generating the data for the
tables to be written in Rust -- that part is exclusively written in C++.
What I don't understand is why C++ doesn't allow both of us (and anyone
else who knows C++) to modify the code to use any scheduling algorithm we
desire to implement. AFAIK you know C++ and can read/write code written in
it without much issue.

>
> > and discuss the generated output.
>
> yes.
>
> however - and - again - i have written to you (either privately or in
> the bugtracker) that you do not have the experience necessary to
> "pre-assess" (estimate) the amount of time it takes to implement
> something.
>
> from experience we have found that your time estimates are usually 100
> to 1000% out (2 to 10 times too short).
>

In this particular case, I did have a better guess of how long it might
take (a week for just generating timing tables) since I did try to
implement a similar program a year or so ago. It took longer than that due
to figuring out C++ on wasm and having to throw away a bunch of code (I
ended up squashing those git commits due to having most of libc++'s source
included and later removed).

>
> > Since there are apparently questions
> > I haven't answered, would you please point me to them? I've kinda lost
> > track of where exactly they are.
>
> they are all in the bugreport.  can i recommend taking the time to go
> over them with someone else?  they should be able to help you evaluate
> what i am talking about.
>

I'll read through them all again, hopefully not loosing track this time. I
was kinda avoiding that since there are quite a few comments.

that time is "resource" that is gone forever and cannot be recovered.
>

Yeah, I understand.

by having these stages it becomes easy to drop "time estimates" on top.
>

I was under the impression that we had decided to skip straight to
implementation because it was expected to take an acceptably short amount
of time.

>
> because it was interesting to you (you wanted to learn rust-wasm,
> which is fine) you bypassed the critical stages which allow us to
> assess properly whether the time it would take would be worth it.
>
> in addition you added an extra requirement - to develop a full
> hardware-level pipeline simulator - without consensus.... *and then
> went straight into it*.  again, because it's interesting to you, and
> again without doing any time estimates or an evaluation of the
> immediate value.
>

I am writing it such that it can be extended to be a simulator later,
currently that is not implemented and takes up like 10 lines of code beyond
what is needed for timing-only.

now, the *long-term* value of what you're working on might be very
> high, however can you see that the entire original discussion has
> effectively terminated?


yeah

  where in *10 days* has there been *any*
> discussion of the original matter?


I get your point, I just originally got the impression that waiting was
intended.

Jacob