sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
ylamarre has joined #m-labs
<sb0>
cr1901_modern, submodules work, only one "sys" clock domain is supported
<sb0>
whitequark, yes
<cr1901_modern>
sb0: I know that only one clock domain is supported, not that it had to be named "sys". >>
<whitequark>
ah well. I guess it's not has hard to clean the gauge as the turbo pump.
<cr1901_modern>
Why does TopLevel have a cd_name field then?
<cr1901_modern>
In any case, I'll just copy/paste the DUT into a new file without the custom clock domain and that should be sufficient for testing.
<sb0>
you can use RenameClockDomain to change whatever the DUT is using to sys
fengling has quit [Quit: WeeChat 1.2]
fengling has joined #m-labs
<cr1901_modern>
That doesn't work- same error (will see if I can duplicate in min component example)
<cr1901_modern>
Updated min component example- same gist. Can you see anything I'm doing wrong?
<sb0>
looks like a bug
<cr1901_modern>
Obviously I'm not trying to make things complicated in Migen. It just so happens that I don't have a choice but to use multiple clocks, and Migen's a bit tougher to use when I have to deal with that.
<cr1901_modern>
Should I file a bug or wait? The problem is most likely in namer.py. I'll take a look in a day or two.
<sb0>
file a bug, I have zero time to spend on migen until september
<sb0>
or have a look yourself
<sb0>
it works when RenameClockDomains isn't at the top, though
<cr1901_modern>
^What do you mean by that?
<sb0>
not directly passsed to Simulator
<whitequark>
sb0: so, would "traits" that rjo wants list the attributes at class level, as opposed to object level?
<whitequark>
if yes, can I get that?
<sb0>
get what?
<whitequark>
the ability to list attributes of a class
<whitequark>
well
<sb0>
we need to support at object level. dealing with class attributes is additional and unwanted complexity in the compiler.
<whitequark>
that's bullshit
<sb0>
no, it's no
<whitequark>
as it goes now, I will create a type per any non-kernel object
<sb0>
some drivers such as the pdq2 mediator request devices dynamically based on the value of some argument
<sb0>
and that cannot be done at the class level
<sb0>
so class level brings just a slightly better syntax, that's all
<whitequark>
which means they will all be incompatible, and they will have functions generated for a cartesian product of (objects × methods)
<whitequark>
i.e. you can't do "a = self.ttl0 if whatever else self.ttl1". plus bloat.
<whitequark>
(it's the same reason, really, since self is a variable)
<sb0>
that's acceptable for now; later, I guess it is possible to unify object types that are found to have the same attributes of the same type?
<sb0>
or a superset of the attributes
<whitequark>
no, the scheme you're proposing for later wouldn't meaningfully work. you have to know beforehand whether they match or not
<whitequark>
meaningfully = the only place where it matters is the inferencer, because the types are essentially erased after that, so unless you have them before you start inference, you don't get any benefit
<whitequark>
you could merge the functions that are using the same object layout, but it's not useful, because LLVM can do that just as well with its mergefunc transform
<sb0>
what about assuming that two objects that have the same type on the host are going to be unifiable, and throw an error if they turn out to be not?
<sb0>
(also, after september, there will be more time to think about fancy typing mechanisms)
<whitequark>
basically, inferring class layout from object instances
<whitequark>
that you can observe
<sb0>
yes. either with dir(), or (better, but more complicated) taking into account only those attributes found during kernel code discovery
<sb0>
what about associating a unique object layout to a given object type found on the host, and add entries to that layout as the attribute discovery goes?
<whitequark>
yes, that's the only reasonable way to do it that I see
<whitequark>
the main complication with that solution is
<whitequark>
a = self.x1 if whatever else self.x2 # both x1 and x2 have an empty layout so obviously they unify
<whitequark>
x1.f(); x2.g() # x1 doesn't have g, x2 doesn't have f; oops
<whitequark>
so you have to verify that every reference in the past still satisfies the layout you have inferred, every time you update the latter
<sb0>
hmm, is that example assuming that self.x1 and self.x2 have the same type on the host?
<whitequark>
same class, different objects
<whitequark>
until you encounter x1.f, it doesn't matter whether x1 or x2 have f or not
<sb0>
x1.f(); x2.g() << did you mean a.f(); a.g() ?
<whitequark>
nope.
<whitequark>
a.f() would just fail, since the inferencer is not able to backtrack and guess which of the two objects you meant
<whitequark>
which is another problem with that design, but one that doesn't result in miscompilations
<sb0>
well, you can assume that two objects with the same type on the host have the same methods - that's not a strong restriction
<whitequark>
who cares about methods? methods aren't special, they're just attributes
<sb0>
actually, the same restriction for those attributes that are used in kernels is totally acceptable as well
<whitequark>
well, you can sort of solve this by creating a type for every class you see, lazily looking up attributes, and also recording every single instance of a class you pull in directly, to ensure they are coherent
<sb0>
"sort of"?
<whitequark>
it's disgusting from the point of view of language design, but it will work
<sb0>
by "lazily looking up attributes", you mean what I described - add entries to the object layout as attributes are discovered?
<whitequark>
yes
<sb0>
and what is disgusting?
<whitequark>
the fact that inference happens at the same time as discovery, the fact that inference happens globally, and the resulting situation where seemingly unrelated changes may make previously valid code elsewhere invalid
<whitequark>
just the usual pitfalls of global type inference, really
<whitequark>
ok, I can do that. (it's not really any easier to implement than the 'dumb' solution above; you still need to infer a type from an object instance and you could as well do it the saner way)
<whitequark>
any harder*
<sb0>
ok
<whitequark>
note though that you can't expect good error messages for that
<whitequark>
I mean, beyond showing the user the two conflicting object instances and attribute name
<whitequark>
I simply don't have the information
imrehg has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 252 seconds]
early has quit [K-Lined]
early has joined #m-labs
ylamarre has quit [Quit: ylamarre]
<GitHub4>
[artiq] whitequark pushed 4 new commits to new-py2llvm: http://git.io/vOyT3