<whitequark>
it cannot possibly work. %1 has to be an immediate and `add` is an argument.
<whitequark>
I upgraded clang to 3.6 and it rightfully rejected this code
<sb0>
whitequark, see comment above about FOSS HDL
<whitequark>
no, this was a bug in clang (that made it accept this) and a bug in libbase, which you wrote
<mithro>
sb0: I'm trying to figure out what the "smallest" migen/misoc code is which still simulates all the stages in a normal full migen/misoc workflow, say a little LED blinker which can end up running on a real hardware...
<whitequark>
at least, git blame says so.
<sb0>
that's stuff I copy pasted...
<whitequark>
amazing
<whitequark>
did they run that code at all?..
<sb0>
mithro, the tutorial, after renaming some modules or function calls, should be essentially right
<sb0>
whitequark, gcc compiled it as well, I think
<whitequark>
I suspect the reason this never angered compilers was that neither gcc nor clang complain about inline functions that are never used
<whitequark>
well, clang before 3.6
<whitequark>
hang on
<whitequark>
mailbox.c has an instance...
<whitequark>
wtf
<whitequark>
sb0: can you show me the assembly for mfspr(1) ?
<whitequark>
(I reinstalled my local compiler to 3.6 and don't want to recompile)
<whitequark>
nvm, I can just use lab.
<sb0>
whitequark, btw I notice that the new kc705 power connector appears to be reliable. so the solution to this problem is to replace the connectors on the mains adapters.
<whitequark>
yes.
<whitequark>
sb0: shall I change the inline function to a macro, or change the inline assembly to use a base register and not this stupid immediate trick?
<whitequark>
I think it works by accident, because the compiler happens to constant-fold it most of the time
<sb0>
macro is easier no?
<whitequark>
both are easy
<whitequark>
the second is changing an operand and a constraint
<sb0>
i'll keep the macro to be closest to the original code
<whitequark>
ok
<whitequark>
hm
<whitequark>
annoying. you cannot make an asm statement return a value
<whitequark>
I think there was some horrible gcc extension, but it's pretty silly to replace one horrible GCC extension with another
<whitequark>
wait, what
<whitequark>
the clang in our miniconda refuses to compile it either
<whitequark>
right. you need -O1.
<whitequark>
this is amazing
<whitequark>
it's literally impossible to compile that function at -O0
<sb0>
ysionneau, you didn't answer my question about the presence of the is_moving() function in the thorlabs driver
<sb0>
oh, actually it has one (limited) use, it returns True when the user is touching the buttons
<GitHub35>
[artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vVImS
<GitHub15>
artiq/master 84d50c4 Sebastien Bourdeauducq: environment,worker_db: mutate datasets from experiments via dedicated method instead of Notifier. Closes #345
<sb0>
whitequark, how does the compiler read it? getattr(object, "kernel_constant_attributes", set())?
cr1901_modern has joined #m-labs
<whitequark>
not the object. the class.
<sb0>
ok. that was my question :)
<whitequark>
btw all our tests pass with LLVM 3.6
<whitequark>
so I think I'll proceed and push it...
<sb0>
whitequark, ok. we still have a bit of time before 1.0-final, and in the meantime there will still be the old package in the main branch
<sb0>
*channel
<sb0>
whitequark, so. if it's the class, updating from setattr_device is somewhat dirty
<sb0>
and if I understand that right - if the user simply does self.setattr_device("dds0") without using kernel_constant_attributes, then they get lousy performance, right?
cr1901_modern has quit [Read error: Connection reset by peer]
<whitequark>
yes. that's why i didn't do it.
<whitequark>
well, it will be somewhat worse
<whitequark>
it's not completely lost. you will get a few pointer loads and some kept FP.
<whitequark>
but FP will be hoisted out of the loop etc
cr1901_modern has joined #m-labs
<sb0>
hmm
<sb0>
what's wrong with loading kernel_constant_attributes from the object, not the class?
<sb0>
the first object is given to you upon @kernel invokation, then you can trace other objects that are also in kernel_constant_attributes ...
<whitequark>
the class is the type, and constness is the property of the type
<sb0>
whitequark, also, kernel_constant_attributes should be documented
<sb0>
it's not right now, right?
<whitequark>
it's not
<sb0>
I tend to think altering the class in setattr_device isn't that bad. it solves the practical user problem...
<rjo>
sb0: I didn't because _NumberEntry seemed to be usable for integers as well where Range is inherently less usable. And the scientific spinbox is not much fun for integers.
<rjo>
but in general. there is still a lot that can be done for physicist-friendly numbers entry. the scientificspinboxes are not perfect at all.
<mithro>
whitequark: You created https://github.com/jordens/unrandom/commits/master right? I'm currently looking at some ISE traces and it appears to be reading from /dev/urandom - any idea how to do a similar thing to make /dev/urandom reads pseudo-random?
<mithro>
whitequark: I would like to only do that for ISE :P
<mithro>
guess I could stuff it into a container
<whitequark>
hook `open`
<whitequark>
just like unrandom does
<whitequark>
or a container, yes
<mithro>
Well, I guess if I hook it to open /dev/zero rather then /dev/urandom that is pretty easy - but I wonder if something would depend on it being more than just a sequence of zeros...
<whitequark>
there's a nonzero probability...
<mithro>
baboom-tish
<GitHub163>
[artiq] whitequark force-pushed master from c68bf13 to 5860220: https://git.io/vYgPK