[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 #204 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #203)
> * forcing visitors of leaf nodes to have to ignore a parameter that
>   is meaningless i do not think is a good idea and i am looking for
>   solutions.
> * another option: the decorator-of-visitors stores in the registry
>   whether the path option is wanted or not.
> * alternative option: leaf-nodes on basic types never receive a
>   path argument. they're just not necessary, so why have it?
> * alternative option: there are *two* functions: one for leaf-nodes
>   (mostly primitive types or any non-iterable class) that never need a
>   path, and one for those that are iterable
> * refinement: auto-identification of leaf-nodes vs tree-nodes:
>   if the tree-iteration yields something of zero length, then it's
>   pretty obvious that it's a leaf-node and the alternative function
>   dedicated to leaf-nodes may be called.

I think you have a misunderstanding of how path and leaf nodes (like int,
float, bool, str) interact:

critically, for each function call, path is the instructions for how to get
from the root node to the current node, path doesn't include any indexes or
anything describing the insides/children of the current node.

Therefore, being a leaf node with no insides/children does *not* imply that the
path is ignored, since the path was never describing the insides/children
anyway, and since the insides/children are the only part we know to be empty
due to being a leaf node.

a good example of why we do *not* want to ignore the path even on leaf nodes is
when visiting the CSV dict for lhau (in major.csv):

{'opcode': '43',
 'unit': 'LDST',
<snip>
 'BR': '0',
 'sgn ext': '1',
 'upd': '1',
 'rsrv': '0',
 '32b': '0',
 'sgn': '0',
<snip>}

the nodes and paths that would be visited:
<snip>
    '0'            path=['BR']
    '1'            path=['sgn ext']
    '1'            path=['upd']
    '0'            path=['rsrv']
    '0'            path=['32b']
    '0'            path=['sgn']
<snip>

as you can see, the strings '0' and '1' get visited multiple times each, the
only way the visitor can tell each '1' apart is by looking at path, which is
where the critical information of *what the '1' means* is (does it mean this
instruction sign-extends? or that it updates?). the only other slightly
reasonable method of getting that information is relying on dict ordering,
which is obviously not what we want to do.

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