[Libre-soc-bugs] [Bug 1094] insndb instruction database visitor-walker is needed
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Wed Jun 21 23:52:38 BST 2023
https://bugs.libre-soc.org/show_bug.cgi?id=1094
--- Comment #225 from Dmitry Selyutin <ghostmansd at gmail.com> ---
Wow. Just wow. Implementation of "pysvp64db operands". The main issue with
operands is that their instantiation is delayed; the record itself just
contains the Operands tuple, which has an operand class to be instantiated and
necessary arguments. And each operand then gets record instance and kinda
"binds" it to itself. With old API, we had to cheat, and established hooks on
Record instead, then traversed operands manually. With the new API, it's
simple:
class OperandsVisitor(InstructionVisitor):
def __init__(self):
self.__record = None
return super().__init__()
@mdis.dispatcher.Hook(Record)
@contextlib.contextmanager
def dispatch_record(self, node):
self.__record = node
yield node
@mdis.dispatcher.Hook(Operands)
@contextlib.contextmanager
def dispatch_operands(self, node):
for (cls, kwargs) in node:
operand = cls(record=self.__record, **kwargs)
print(operand.name, ", ".join(map(str, operand.span)))
yield node
The trick here is MRO; Operands is simply declared as "class Operands(tuple)",
and the first hook to be matched is picked. Previously we had to create classes
like Dict, Tuple and similar, now we just match MRO. And, since we know
Operands will be eventually called from Record (actually
Record.MarkdownRecord.Operands), we simply catch the record which was visited
before and use it for instantiation. No custom Tuple classes, no cheat hooks on
Records.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list