[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