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

[lkcl]

On Tuesday, November 22, 2022, Dmitry Selyutin <ghostmansd at gmail.com> wrote:
> Hi folks,
>
> I'm slowly filling task 939 for MoU. Here are the questions and
> thoughts I have so far.
>
>
> * EUR 6000? c-based Power ISA decoder compiler
>
> Is this task about decoding the instructions? The same we have for
> binutils, but, this time, for a simulator?

that is 50% of the task. the other 50-ish % is finishing
off the nmigen c compiler and morphing its output to produce
meaningful useful *stand-alone* c code

the alternative is to both:

a) autogenerate the ENIRETY and i mean everything behind
  PowerDecoder2 (as a nmigen backend)
b) produce aurogenerated c that does the exact job of
  PowerDecoder2 but instead in c

>  This task could reuse most
> of insndb and some of sv_binutils.

50%... yes.

50%... (PowerDecoder2) no.  the PowerOpSubset classes all
need c code.  DecodeInA needs c code.  DecodeAImm needs c
code.  the remap subsystem needs to be hooked in.  over
2,000 lines of deeply complex code with huge numbers of
exemptions and customisations developed and learned over
a TWO year period.

which is why the quickest and least risky route is the
nmigen c backend.

> Ideally some bits of sv_binutils should be decoupled into a
> backend-agnostic module. Once that is done, we could re-use that
> module for binutils, simulator and clang.

yes. at last.

>
> * EUR 6000? c-based Power ISA markdown pseudocode compiler
>
> What is expected in the scope of this task? The same code we generate
> for Python but just in C?

yes.

> I'm not sure the current parser we have maps
> well to the C code generation, though.

it can be made to work.  ply is entirely output-agnostic
and the lexer needs zero modifications of any kind.

two approaches, python-to-c i.e. use the python AST and
replace ALL uses of astor, even to the extent of passing it
in as a parameter.

second approach, rip out the return results, find a c-based
AST library from somewhere, and use it.

it is far less work than first seems.  first unit tests should
begin successfully LITERALLY within under 45 minutes.

no it is not acceptable to propose alternative parsers.
that option has already been eliminated as it is too much
work, too much code, for zero benefit, for a small team,
producing unreadable, unmaintainable and unmanageable code
that is too complex for anyone but the original and sole
author.

we HAVE to write MAINTAINABLE and SIMPLE code
and that means sacrificing certain coding techniques
and even algorithms because they require too advanced
engineering knowledge to introduce to new developers.

>
> * EUR 8000? userspace ABI in simulator
> * EUR 6000? userspace ABI in ISACaller (pypowersim)
>
> What is implied under "ABI" here? Are we speaking of supporting the
> (Linux?) system calls?

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

> Do we mean the full ABI like, say, System V
> Application Binary Interface?

if it is effectively the POSIX ABI then yes.

>
> * EUR 6000? continuing the SFFS userspace distro from NGI POINTER
> https://bugs.libre-soc.org/show_bug.cgi?id=860
>
> The task provided is closed as "resolved fixed". Is it still actual?

that is a guide and should be linked to the bugreport.

>
> * EUR 8000? SVP64 support in simulator
> * EUR 2000? integrate cavatools into Test API (running unit tests)
>             (via pygdbmi, via cavatools remote machine gdb interface)
>
> These seem to be clear, it looks like I only need to raise the relevant
tasks.

yes.

>
> Last but not the least: we have many binutils-related tasks. At least
these:
> 1. Support missing instructions, #958: looks like completed, unless
> new instructions were added recently.
> 2. Support missing specifiers, #976: needs the budget. Perhaps some
> from #860, if this is completed? Perhaps it can be merged with #958 if
> we change the description a bit.
> 3. Implement binutils-gdb tests (no task yet). This needs its own
> budget for sure.
>
> Considering the amount of binutils stuff, should we consider these
> tasks above as candidates for #939 grant at all, or should we change
> the parent task?

only if the budgets for the remaining tasks are inadequate in
some way.

l.