[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=64

--- Comment #41 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #37)

> >  does the generator approach make sense?
> I had been planning on the Data API being a tree where the links were named,
> similar to directories and files in a filesystem. This is similar to a
> subset of C that has only structs and integers.

 yyehh, the names can be flattened at the IR (verilog) level because the
 IR (verilog) does not support objects.  Record uses underscores to
 concatenate the name of the parent object (if given) to the child
 object (if given, one being auto-created if it isn't)

 _spec now exists and it actually dynamically analyses the function it's
 calling to find out if it has a name or not:

https://git.libre-riscv.org/?p=ieee754fpu.git;a=commitdiff;h=bc7bbd60c80c44fc6d675c727938c289e2b9a631

 so this gives developers the *option* to explicitly give more complex
 structures a bit more information.

 the reason for doing so is that i looked at the code that *requires*
 name, and went, "ugh, ugly".

    def ispec(self, name):
        return (Signal(16, name="%s_sig1" % name),
                Signal(16, name="%s_sig2" % name))

 that's ugly....

 class Example2OpClass:
    def __init__(self):
        self.op1 = Signal(16)
        self.op2 = Signal(16)

    def ispec(self):
        return Example2OpClass()

 ... that's not.


> I think the nested tree of iterables makes more sense, though we will have
> to be careful about member variable ordering and that dict-like objects
> return the list of keys rather than values.

yes, absolutely: the only reason that Visitor2 accepts a dict as an option
is because when the input is viewed as free-form "things that happen to have a
__getitem__ function", the actual ordering of the application of the
function on the matched pair doesn't actually matter.

reason: the application of the function to a matched-pair (like zip)
is *independent* of the application of the function to any *other*
matched-pair.

where it really really would start to matter is in the single-visitor
case (where i've not added support for dicts for precisely this reason)
where typically that's used to concatenate the leaf-nodes together, i.e.
the ordering is critically important.

mandating use of OrderedDict makes that problem go away, with the penalty
that the freedom within Visitor2 (where it really doesn't matter) is
(unnecessarily) curtailed.

needs thought.  and/or properly documenting.

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