[Libre-soc-dev] insndb: further directions

[Dmitry Selyutin]

On Sat, Sep 9, 2023 at 12:41 AM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> bugs bugs bugs, always subdivide into bugs but the list is
> a good place to start unstructured thought, when there is this
> much detail and complexity.

Yeah I know. But I had to raise them here first to have a starting point.
Also, after several comments in 979, I realized I had to propose
things together so that they form kind of an high-level overview.

> * OPF ISA Confidentiality prohibits me from mentioning
>  what is in upcoming specs.  however for immediates mapping
>  in the "machine-readable" format please hold off for now,
>  i cannot say more. likewise aliases.

Just a question, if you're allowed to answer that: do you mean vanilla
aliases too, or just the new ones which we intend to bring with SVP64?
If we could avoid all aliases -- that'd be great. For now binutils
keep these along in the same huge table.
If we want the code to be used by binutils, we have no other choice
but support vanilla aliases.
Luke, please, feel free not to answer that, I just don't know how much
you're allowed to share.
The reply would help to at least understand whether we need vanilla
aliases/operands or not.

> * SVP64 format yes there is a section that is in "something
>  that is easy to convert to CSV", it is really obvious how
>  that would work, one column with Rc, one with the "5 bit Mode"
>  and so on.

This must be a simple yet powerful format. These actually form a kind
of a tree-like hierarchy.
Frankly, this task is the most difficult one. That said, its
completion unblocks a lot of tasks.
I'm especially concerned with the docs vs code synchronization.
It's mad to sync docs, Python and manually written binutils.

> * separating out libopid from openpower-isa, i would rather
>  the spec files moved to an entirely separate repo, that
>  both then can use.  opspec or opisa or something.
>  git submoduled into the openpower/ directory.

Yes, exactly, totally matches my view on that! A separate repository
with the specs and machinery to fetch them into the Python code.
The opid library and openpower-isa would then rely on this repository.
The idea is that people have three repos instead of one:
1. opisa: They come and see specs and parse them into the code to fit
their needs.
2. libopid: They fetch libopid repository and generate the library to
use in binutils or whatever.
3. openpower-isa: They are brave enough to dive into our world.

Item 1 can be split into "opspec" and "insndb": not everyone needs to
parse this, and not everyone wants to have the code mixed with the
specs.
In the latter case, the dependency chain would be:
opspec <- insndb <- libopid
opspec <- insndb <- openpower-isa

-- 
Best regards,
Dmitry Selyutin