[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 #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #11)
> turns out subclassing Record is supported, but not Signal.

It is now, as of appx last week, yes.
Whitequark and I discussed this in some detail, and I managed to convince wq
to fix a bug related to iteration that
was stopping eq, Cat and many other things
from working.

Basically Record is viewed by whitequark
as a contiguous sequence of bits, hence
why it derives from Value.

In the discussions that we held she acknowledged
that that is a conceptual perspective,
reality is, the internal structure (fields)
is clearly an ordered bank of signals.

Iteration in python is done as follows:

If obj has __iter__ call it in sequence,
accumulate its yielded results, one by one

Else, create an integer sequence and call
__getattr__ until that raises an AttributeError.

The addition of __getattr__ originally was
intended to make it possible to refer to
Fields by name. rec.src1 where layout has
src1.

Unfortunately that had the unexpected side
effect of interfering with iteration.

I asked whitequark to add __setattr__
to Record, she refused, citing that it
does not fit with how Record is supposed
to be used (as a sequence of bits)

I asked whitequark to add __iter__ because
not having it causes assignment on flattening
to go haywire, creating a massive array of
bit-level assignments even between two
Records.

With __iter__ added, there is no detrimental
side effects and the assignment of
Record to a sequence of Signals is done
with the expected minimum of eq statements

This is still potentially open to debate
if we can create a suitably small demo
use case.

__setattr__ unfortunately wq remains closed
to feedback, viewing Record as a sequence
of bits, not a hierarchical sequence of
Signals-that-happen-to-be-bits.

Therefore we need to create a class that
derives from Record and adds both functions.

I considered monkey-patching Record, however
if deriving from Record is indeed supposed
to work, bugs can be raised if any uses of
type have been missed, with the monkey patch
to be removed once the bugs are fixed.

RecordObject has the two functions.
It works very well.

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