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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Jun 3 10:47:17 BST 2023


--- Comment #10 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #9)
> db.py instead of types.py? "insn/db.py" "insn/asm.py"?

Ah sorry, I totally missed this. Well, I also thought about db.py, but came to
conclusion that db.py module would provide a special script itself. Now it's in

This commit provides pysvp64db script, which now can list all instructions.
I'll play more with this script and its possible commands.

> maybe types.py works better, dunno.

I was thinking about core.py or something like this. But for now I'm keeping
types.py to concentrate on visitors.

> suggest a separate "visitor.py" file.

Perhaps yes, if we'll have some concrete visitor implementations to be reused.
For now I just added a "default" Visitor class into types.py, and that,
combined with approach suggested by Jacob, actually was already sufficient to
write a simple script which dumps all instructions.
Another part of "visitors" is that we actually have more stuff to be "visited".
Not only the database itself, but, for example, all possible fields in RM. Or
all possible specifiers. And so on. But at this point it seems that all these
chunks might be just separate context managers (like with db and record

> insndb/asciidump.py?  insndb/print.py?
> btw if you want a hint on doing indentation: the "child_begin" function
> increments "self.tabdebth", and "child_end" function decrements it.
> real simple.

I think this should be handled in concrete visitors: not all of them need
tabulation. Perhaps the inherited visitor could simply track this on their own?
I'll think about it when I'll move to binutils.

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

More information about the libre-soc-bugs mailing list