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

[Dmitry Selyutin]

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 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.


> 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.

I'd argue with MAINTAINABLE and SIMPLE as one who debugged and
modified it, especially since you write it in CAPS. 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.


> > * 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

It looks like that you rather imply something like QEMU user mode; is
it what you mean? 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? 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.


> > Do we mean the full ABI like, say, System V
> > Application Binary Interface?
>
> if it is effectively the POSIX ABI then yes.

To the best of my knowledge, there's no such thing as POSIX ABI (and
never will, since POSIX is not about ABI). Do you probably mean SVR4
ABI? Is it kinda "budget reserved to deal with ABI-related issues in
scope of supporting cavatools"? It's not clear what needs to be
developed here; this also looks like something to be handled by the OS
mostly (except for QEMU-like user mode emulation, which is probably
what you meant).


> > * 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? And I simply can enter it
as is into 939?


> > 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.

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.


-- 
Best regards,
Dmitry Selyutin