[Libre-soc-bugs] [Bug 979] Implement C-based Power ISA decoder compiler

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=979

--- Comment #57 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Andrey Miroshnikov from comment #56)
> (In reply to Dmitry Selyutin from comment #55)
> If you don't mind me butting in, I really like the idea.

No, I'm really glad that you are interested in this, and it's perfect that I
can know your opinion on this. It's difficult to develop something without a
feedback; that's one of the reasons I'm writing so many comments during the
development. :-)

> Because, to my understanding, all supported instructions of the disassembler
> can be tested with this python script (eventually, probably
> out-of-scope/unnecessary right now).

Exactly! I suspect we'll unlikely be able to test each and every instruction at
this point, since this took literally months and separate works on rewriting
Python asm and disasm to reach even the previous point, but the overall idea is
that they must be on par, Python version and C version. And they kinda
complement each other: C code is based on Python code, but at some places in
Python, where we strive for speed, we'll have to switch to C code.

> And having opid-dis as a standalone tool means it can eventually be matured
> to become a full disassembler (as you have already rationalised).

I have some doubts on the latter part, to be honest. I have no illusions on us
being used as a replacement on binutils or clang: they are de facto standard.
If we want to survive -- their support is mandatory. However, I'm really,
really tired of adding all code in binutils manually, and doing the same work
for clang would be completely insane. Since we basically want to support all
our code in binutils and might (and likely will) opt to support it in clang, we
basically want to have everything ready for writing assembler and disassembler.
And the best way to ensure that we indeed have everything ready for assembler
and disassembler is writing at least trivial verions of them. Plus it helps to
invent the overall API architecture: updating it on the later stages would be
quite a difficult task.

> Making the future work of the assembler easier by having this
> executable/python test framework sounds great as well.

Yep. I also have a confession to make: we currently have quite a limited set of
tests for assembly and disassembly in Python, and completely lack them for
binutils. The latter is mostly caused by the fact that until recent we lacked a
way to generate so much code, we're just in the beginning of the way. Until
insndb, we had no generalized and uniform way to process all data we had in
repository; until visitors, we had no good way to re-use this information for
other means (including code generation).

> I'm sure we all agree that autogenerating is better. Perhaps another task we
> can allocate some funding to from one of the grants that need to be used up?

Yep, I think we need to have it. Especially if we want to support other tools,
like clang. That's actually the main reason why I chose to implement this code
as a library with explicit dis-related parts. Besides assembler, I also shared
some future directions. I'll try and list them again in a separate comment
(there is some information here and there, some also in my head). Then we can
put priorities to these tasks and find volunteers who can help with them:
there's a huge amount of work to do, I will be glad for help from all people
interested.

-- 
You are receiving this mail because:
You are on the CC list for the bug.