[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 #12 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Dmitry Selyutin from comment #10)
> (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,

i ran *immediately* into import problems due to common-names "import dis",
and the same would happen on "import types".

so *temporarily* i invented some names

commit aaaecc47a8bbe21bc047e589e34bec6e18f928f6 (HEAD -> master, origin/master)
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Sat Jun 3 12:47:30 2023 +0100

    using names of modules that are identical to commonly-used python modules
    (even at the leaf-node) is causing import problems

commit 9546d80ef122b4f53b61dc1f3997a2ad70c139bd
Author: Luke Kenneth Casson Leighton <lkcl at lkcl.net>
Date:   Sat Jun 3 12:45:35 2023 +0100

    import dis overloads naming of modules already in python3,
    and stops functions from importing


> but came
> to conclusion that db.py module would provide a special script itself. Now
> it's in repository:
> https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> h=78231140441402bec1dedbe4e97238cb9597b96f

like it

> 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.

aaabsolutely.  it will extend down further.

> 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 methods).

     with Visitor.record.rm.extra(blah)

> I think this should be handled in concrete visitors: not all of them need
> tabulation.

ok so we are basically subdividing into Model-View-Controller here.

i *think* - i am not certain - that you might be conflating/merging
two of those two together.

> Perhaps the inherited visitor could simply track this on their
> own? I'll think about it when I'll move to binutils.

the idea of MVC is that Visitors are passed *both* the data *and*
"what to do on it".

the "what to do on it" has an API (child_before, child, child_end)
which the *Visitor* knows about.

the idea of "tabulation" is *not* for "All Visitors".  it's for
*that one Visitor* to keep, as a *local variable*, the "current tab depth".



def visit(db, visitor):
    with visitor.db(db):
        for i, insn in enumerate(db):
            with visitor.insn(i, insn):
                for i, operand in enumerate(insn):
                    visitor.operand(i, operand)

class MyDemoVisitor:
    def __init__(self):
        self.tab = 0
    @property
    def tabs(self):
        return " " * 4 * self.tab
    @contextmanager
    def db(self, db):
        self.tab += 1
        print(self.tabs + "before insns")
        yield
        print(self.tabs + "after insns")
        self.tab += 1

    @contextmanager
    def insn(self, insn_index, insn):
        self.tab += 1
        print(self.tabs + "before operands")
        yield
        print(self.tabs + "after operands")
        self.tab += 1

    def operand(self, operand_index, operand):
        self.tab += 1
        print(self.tabs + "operand")
        self.tab -= 1

generates output like:
before insns
before operands
operand
operand
after operands
before operands
operand
operand
operand
after operands
after insns

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