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 quit [Quit: ylamarre]
<sb0>
whitequark, dds_init works fine on master/kc705 here. i guess rjo tested it on the pipistrello as well
<sb0>
shoud I try on pipistrello?
<whitequark>
yes, I think so
<whitequark>
I could not trace it to anything I could have broken
<sb0>
are you trying master?
<whitequark>
I think I tried master, yes
<GitHub101>
[misoc] whitequark pushed 2 new commits to master: http://git.io/vOZTW
<GitHub101>
misoc/master 36e03ec whitequark: libdyld: R_*_RELATIVE never specify a symbol.
<GitHub101>
misoc/master b8a5568 whitequark: libdyld: handle existing but undefined symbols during lookup.
<GitHub151>
[misoc] whitequark force-pushed master from b8a5568 to 6a1b0b3: http://git.io/LjONPA
<GitHub151>
misoc/master 6a1b0b3 whitequark: libdyld: handle existing but undefined symbols during lookup.
<whitequark>
phew, this nearly works
<whitequark>
one unaligned access left...
<cr1901_modern>
So that's what your question on twitter was about. Of course I missed the point of it.
<whitequark>
YES
<whitequark>
IndexError(index {0} out of bounds 0:{1}, 10, 1, 0)
<whitequark>
it threw and caught an exception within Python code.
<whitequark>
speaking of things that work, binutils. fucking piece of shit. i spent at least six hours chasing a s/TRUE/FALSE/ which was copy-pasted by whoever added the OR1K support
<whitequark>
and it's not even some kind of tricky relocation. it's the most barebones possible one. but noooo
<GitHub174>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vOZL2
<stekern>
whitequark: those relocations are only used in eh_frame, right?
<whitequark>
stekern: as far as I am aware.
<whitequark>
they weren't ever emitted by LLVM until I patched it. not sure about gcc, but probably same.
<whitequark>
I can't imagine any other reason a PC-relative data relocation would appear. all non-DWARF ones in regular data should be absolute since the frontend doesn't know to add the address of relocation when reading
<stekern>
gcc should be emitting .eh_frame, but maybe those relocations aren't being used there
<whitequark>
they should be used with -fPIC
<whitequark>
well, it could probably also use absptr encoding
<whitequark>
sb0: hm, brg_ddsinstall doesn't hang here either anymore
<whitequark>
not sure what that was
<GitHub62>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vOnDA
<whitequark>
sb0: ok, I have questions about the programming model of ARTIQ
<whitequark>
do I understand this correctly...
<whitequark>
you start from some subclass of Experiment. there is an implicitly created instance of Experiment on the device.
<whitequark>
you use attr_whatever to give the class of that instance the corresponding attributes
<whitequark>
every attribute, something like TTLOut, also pulls in its corresponding class and all its @kernel functions
<whitequark>
this all happens recursively.
<whitequark>
what would be really great is if I could discover the full extent of the classes whose attributes the kernel can call before even starting inference
<whitequark>
interleaving inference and discovery is... it's possible, but it's kind of gnarly