[Libre-soc-dev] Task 939 and its subtasks

[lkcl]

On Tue, Nov 22, 2022 at 7:01 PM Dmitry Selyutin <ghostmansd at gmail.com> wrote:
>
> On Tue, Nov 22, 2022 at 9:12 PM lkcl <luke.leighton at gmail.com> wrote:
> >
> > which is why the quickest and least risky route is the
> > nmigen c backend.
>
> I can provide some help with parts which attempt to re-use insndb or
> binutils, then, as I'm a complete noob in nmigen. But yes, my thoughts
> are the same, this should be closer to nmigen: insndb sits on a lower
> level and would simply require to invent too many abstractions.
> Re-using some parts of it in decoders or binutils or clang or in other
> places is a bit of a different story; but creating a different decoder
> from the ground -- no, that'd take too long.
>
>
> > it is far less work than first seems.  first unit tests should
> > begin successfully LITERALLY within under 45 minutes.
>
> I'd take this with a grain of salt. :-)

no, really:

* write one expression, "RA + 3"
* *completely* ignore the entire rest of the code, don't even
  remove the parts that convert to python
* write one unit test
* get the "Number" function working
* get the "Register" function working
* get the "+" (binary operator) function working
* call the test.

if that takes more than 45 minutes then something is very very wrong.

from there, the confidence builds massively because all you have
to do is say, "NEXT".  pick any function (any one of the BNFs),
create associated unit tests, and it's done.

with there being so few BNF expressions, it quickly becomes
"routine".

>
> > no it is not acceptable to propose alternative parsers.
>
> Never intended to propose. I assumed that the task was about writing
> the same stuff like we have but with a C code generator. If we can
> generate a sufficiently good AST from what we have in Python, that's
> perfectly fine with me.

with cython existing and with the pseudocode syntax being both so insanely
simple this should be perfectly reasonable.

the "fallback" position which we deployed in the verilog2nmigen converter
was to actually return a str() - an actual string - comprising the actual
code that was otherwise "too complex" (or couldn't be bothered) to return
in python AST.

this also worked remarkably well and was successful.

the "gotchas" in c are that you have to declare variables.  well, just
accumulate those, drop them into a separate data structure during
the BNF walk, and now you have 2 data structures, one of which
may be post-process-substituted into the other.

> I'd argue with MAINTAINABLE and SIMPLE as one who debugged and
> modified it, especially since you write it in CAPS.

three other people have demonstrated self-learned capability to
both comprehend, debug, and modify the python-ply-based parser.
this is enough empirical evidence to support the hypothesis that the
code is both simple and also maintainable.

> But points about
> costs of developing a new parser and introducing to new developers --
> I couldn't agree more. With the current code, we have at least several
> people who know it, and can help newcomers with it.

yes.

> > yes.  ISACaller a small subset initially, or stubs,
> > is sufficent. ISACaller will *actually* need to implement them,
> > whereas cavatools cheats so it is more unit-test orientated
> > to confirm
>
> It looks like that you rather imply something like QEMU user mode; is
> it what you mean?

exactly like qemu user mode!

> Otherwise it's not clear what's needed. The system
> calls implementation, the exact ids, the arguments, the jump table,
> etc., is handled by the operating system. What is exactly needed on
> the simulator's side?

we'll determine that by what occurs during the actual development.
this will be a task that follows the heuristic "success by limiting what is
done during the available budget such that what is achieved is DEFINED
to BECOME the scope of the task".

rather than "oh dear we massively overspeciified the amount of work
therefore we cannot possibly even complete it therefore we are not
going to be able to even put in an RFP".

> Most of the system calls are ISA-agnostic; there
> are some exceptions, like set_thread_area, get_thread_area, or pipe(2)
> inconsistencies w.r.t. ABI, but these are rare.

play it by ear.

> To the best of my knowledge, there's no such thing as POSIX ABI

then ignore my response because it will be misleading.

> > > * EUR 6000? continuing the SFFS userspace distro from NGI POINTER
> > that is a guide and should be linked to the bugreport.
>
> So this is just a completed subtask, right?

yes, as a guide - example and continuation - which must - to repeat - be
linked *TO* the bugreport THAT MUST be created.

> And I simply can enter it
> as is into 939?

no absolutely not. payment has been received for that task,
from a completely different project.  look at the milestone:
it says "NGI POINTER", doesn't it.  it has a parent task
"912" which is "NGI POINTER".

> > only if the budgets for the remaining tasks are inadequate in
> > some way.
>
> I don't know where to get the budget for items 2 and 3. The item 2 is
> quite a simple one but will need some time for sure. The item 3 is a
> big task which must be done anyway. The only option for these tasks,
> if I incorporate them into 939, is to steal budget from other tasks,
> and those look like budget-critical already

ah.  they're big enough such that this grant *becomes* starved,
because the scope of work has been increased so much that
they are now much bigger than originally intended.  ok, then
yes, they should probably move to the other Grant, but bear in
mind that if you do that, it means delaying payment because
they're now on *another* Grant that has to have its MoU
*developed* (written), let alone agreed.

which is why we initially intended these as very small tasks,
so that they could go under cavatools and get you some EUR,
quickly.

l.