[Libre-soc-bugs] [Bug 1094] insndb instruction database visitor-walker is needed

[bugzilla-daemon at libre-soc.org]

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

--- Comment #5 from Dmitry Selyutin <ghostmansd at gmail.com> ---
I checked the visitor branch, and I have some thoughts to share.
1. If we take a 3rd-party code, please keep it as is. Yes this includes
formatting. No need to adopt.
2. I don't really like what I see in pyomo. It seems that the overall
implementation is bloated, complex and too pyomo-way-centric (unsurprisingly).
This seems way more complex than it should've been.
3. The APIs you refer to (beforeChild, afterChild, etc.) are actually
deprecated.

What I like, in contrast:
1. Something dead simple as html.parser visitors. Yes they are not as generic
as pyomo, but there's no need to be generic in this exact case. We handle
insns, not anything in the world.
2. The html.parser approach can be augmented with contextlib, like Jacob
suggested. I have to check and play around the code, because I rarely used
context managers before.

Now on the order of the subtasks. I'd start with binutils. I know you already
tired of this never-ending-journey, but here's the rationale.
1. binutils code must be updated anyway with respect to assembly (and to lesser
degree disassembly). You remember that I started binutils when we had the old
assembler, so binutils assembly follows old assembler's principles.
Disassembler, in contrast, relies much more on autogenerated code; but still
not enough. Too much manually-written code. With visitors, we can generate much
more code to avoid manual synchronization between these code bases.
2. Despite that we added missing specifiers, we never had a chance to sync and
especially check whether the manually written code works everywhere (quite
unlikely). Fixing these scenarios, especially for assembly, will simply waste
the time unless we rely more on the generated code.
3. binutils is the most active insndb user, and I know its structure (almost)
perfectly.
4. If implemented carefully, the same principles from C-generator-visitors
(encoding/decoding) can be reused for C-based Power ISA decoder. Perhaps even
to the point that we can generate the same code and use it in different places.
5. It's a good candidate considering the size (about 700 LOC).

In an ideal world, even assembly/disassembly *inside* insndb could be
implemented via visitors. However, this is too fragile and complex target to
start with. The C-generator-visitors are much better targets, and binutils
seems to be the best to sharpen a skill and test the overall approach.

What do you think?

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