[Libre-soc-dev] insndb: further directions

[Dmitry Selyutin]

I forgot the item #9:

9. Cross-check libopid, binutils and Python
I'm in process of writing tests which check libopid vs insndb, but
likely we should have the tests which are binutils-exclusive. I guess
we cannot push such a massive extension to the upstream without these
tests.
Prerequisites: all tasks which are prerequisites for binutils.

--
Best regards,
Dmitry Selyutin

On Sat, Sep 9, 2023 at 1:30 AM Dmitry Selyutin <ghostmansd at gmail.com> wrote:
>
> 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



-- 
Best regards,
Dmitry Selyutin