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
<sb0> whitequark, so no -fPIC and no or1k-linux binutils either?
<sb0> can you update misoc (maybe revert my BIOS size extension commit then) and the doc (including removing -DLLVM_ENABLE_ASSERTIONS=ON)?
<sb0> cr1901_modern, what is the point of such a function
<sb0> + def __init__(self, flash_proxy_basename=None):
<sb0> + GenericProgrammer.__init__(self, flash_proxy_basename)
<sb0> and why not use openocd instead of writing yet another adhoc JTAG tool?
<sb0> that would solve the flash issue
fengling has quit [Ping timeout: 245 seconds]
fengling_ has joined #m-labs
<GitHub81> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vYQH0
<GitHub81> migen/master abbb76c Sebastien Bourdeauducq: ise: do not use LCK_cycle:6 by default
travis-ci has joined #m-labs
<travis-ci> m-labs/migen#66 (master - abbb76c : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
<GitHub187> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vYQH5
<GitHub187> artiq/master 9036841 Sebastien Bourdeauducq: ttl: remove timestamp function...
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#349 (master - 9036841 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
<GitHub61> [artiq] jordens pushed 1 new commit to master: http://git.io/vYQd5
<GitHub61> artiq/master 278570f Robert Jordens: examples: add TDR toy example
mumptai has quit [Ping timeout: 256 seconds]
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#350 (master - 278570f : Robert Jordens): The build has errored.
travis-ci has left #m-labs [#m-labs]
mumptai has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
fengling_ has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 272 seconds]
<GitHub117> [artiq] jordens pushed 1 new commit to master: http://git.io/vY7YJ
<GitHub117> artiq/master ebbbdcf Robert Jordens: examples/tdr: cleanup
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#351 (master - ebbbdcf : Robert Jordens): The build has errored.
travis-ci has left #m-labs [#m-labs]
fengling__ has joined #m-labs
fengling_ has quit [Ping timeout: 245 seconds]
<sb0> rjo, so what do we do about slices? deprecate []?
<sb0> there will still be a few corner cases in the verilog backend, e.g. verilog compilers will probably choke on the result of fslice(0, 0, 10)
<sb0> but at least the front end language is coherent
cr1901_modern1 has quit [Read error: Connection reset by peer]
<whitequark> sb0: no, not quite
<whitequark> or1k-linux binutils are still needed to build the kernels themselves
<whitequark> but no -fPIC in bios and runtime
<sb0> can't llvm use its integrated assembler?
<whitequark> sure
<whitequark> but you can't make a shared object without a linker
<sb0> so why does it need binutils?
<sb0> is that thing going to run or1k-linux-ld at each kernel compilation?
<whitequark> sure
<sb0> meh
<whitequark> first, I would still figure out why BIOS CRC doesn't match
<whitequark> could point to a latent bug somewhere, could not
<sb0> I'm worried about the speed of that thing. won't writing the binary file to disk, running ld, reading the binary back be a bit slow?
<sb0> in addition to the rest of the stack not being that fast as well
<whitequark> -pipe
<whitequark> though frankly, even if I wrote it to the filesystem, I doubt you'd notice any difference
<whitequark> since it just goes to the cache and then from the cache.
<whitequark> not really any different from -pipe on a system that's newer than from 1995
fengling has joined #m-labs
fengling__ has quit [Ping timeout: 245 seconds]
<whitequark> sb0: reproduced BIOS CRC failure on pipistrello
<whitequark> wait, no
<whitequark> oh, it's an .fbi, even if it's called .bin
<whitequark> sb0: ha, well
<whitequark> -fPIC. GOT. you can't get the address of _edata by making a global with the same name
<whitequark> since you'll get the address of a GOT entr
<whitequark> I replaced &_edata with assembly and now it passes
<whitequark> though obviously no point in committing
MiW has quit [Ping timeout: 250 seconds]
MiW has joined #m-labs
<whitequark> sb0: oh, and there's another issue
<whitequark> I'm not sure what happened with gcc, but right now, you get a 1-byte .data in the final executable
<whitequark> no, hm, that's wrong
<whitequark> so I have this:../../mkmscimg.py bios.bin
<whitequark> 95270fb5
<whitequark> _ftext 00170000 _edata 00176bac
<whitequark> BIOS CRC failed (expected 270fb500, got e9f9e84a)
<whitequark> it's clearly a fencepost error. but how
<whitequark> oh
<whitequark> .rodata's *virtual* size is correct, but *file* size is one byte shorter
<whitequark> so the virtual size has been aligned, but the file has not had zeroes appended
<whitequark> and you have probably never noticed because GCC aligns constants differently, or something like that
bentley` has quit [Ping timeout: 252 seconds]
<GitHub191> [misoc] whitequark pushed 2 new commits to master: http://git.io/vY5CO
<GitHub191> misoc/master a4e14f1 whitequark: Don't build base libraries and BIOS with -fPIC after all.
<GitHub191> misoc/master 8db098d whitequark: Make sure the BIOS file ends on an aligned boundary....
<GitHub160> [artiq] whitequark pushed 1 new commit to master: http://git.io/vY5RN
<GitHub160> artiq/master c40ae9d whitequark: MiSoC is not built with -fPIC anymore, remove support code for that.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#352 (master - c40ae9d : whitequark): The build has errored.
travis-ci has left #m-labs [#m-labs]
<GitHub98> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vY5gI
<GitHub98> artiq/new-py2llvm fd46d8b whitequark: Merge branch 'master' into new-py2llvm
_whitelogger____ has joined #m-labs
<whitequark> why do we need llvmlite-build-as-debug-on-windows.patch
<whitequark> ?
_whitelogger___ has quit [Ping timeout: 240 seconds]
[florian] has joined #m-labs
[florian] has joined #m-labs
<sb0> on a 7-series FPGA's differential input, is it possible to use the two ISERDESE2 blocks separately? (i.e. deserialize the same data, but with different IDELAY values)
<sb0> ysionneau, ^
<whitequark> sb0: so I am rebuilding pipistrello bitstream now
<whitequark> ~hour and counting?!
<sb0> hmm, never happened here
<sb0> unless there were gross timing problems
<sb0> maybe from Robert's latest changes?
<whitequark> yes
<whitequark> PAR is going on for 35 minutes...
<whitequark> rjo: I fixed your linking issue
<GitHub70> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vY5dR
<GitHub70> artiq/new-py2llvm 3378dd5 whitequark: Fold llvmlite patches into m-labs/llvmlite repository.
_whitelogger____ has joined #m-labs
<GitHub110> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/vYdmt
<GitHub110> artiq/master b548d50 Sebastien Bourdeauducq: test/coredevice: use ttl_out for PulseRate (loop is less available)
<GitHub110> artiq/master 1d34c06 Sebastien Bourdeauducq: rtio: detect collision errors
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#353 (master - 1d34c06 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
fengling_ has quit [Ping timeout: 245 seconds]
fengling_ has joined #m-labs
ylamarre has joined #m-labs
ylamarre1 has joined #m-labs
ylamarre has quit [Ping timeout: 246 seconds]
* sb0 ponders going to lca
siruf has quit [Ping timeout: 256 seconds]
siruf has joined #m-labs
cr1901_modern has joined #m-labs
ysionneau has quit [Ping timeout: 255 seconds]
ysionneau has joined #m-labs
attie has quit [Ping timeout: 272 seconds]
attie has joined #m-labs
antgreen has joined #m-labs
<GitHub175> [artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vYbeu
<GitHub175> artiq/master a8c13cb Sebastien Bourdeauducq: gui: fix NumberEntry min/max
<GitHub175> artiq/master 86fef7b Sebastien Bourdeauducq: master: do not scan experiments starting with '_'
<GitHub175> artiq/master 1ddb192 Sebastien Bourdeauducq: add speed benchmark
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#354 (master - 6b98f86 : Sebastien Bourdeauducq): The build has errored.
travis-ci has left #m-labs [#m-labs]
antgreen has quit [Ping timeout: 252 seconds]
bentley` has joined #m-labs
<sb0> whitequark, do the lit-tests integrate with coveralls.io?
<whitequark> sb0: they should
<whitequark> what does python use for coverage measurement?
<whitequark> ok, it looks like I will need to provide a plugin like this: https://nose.readthedocs.org/en/latest/plugins/cover.html
<whitequark> it will go into lit-test/harness.py
<sb0> a lot of the uncovered code is device drivers ...
<sb0> or code that otherwise needs hardware
<whitequark> sb0: can you please fix travis?
<sb0> I have never really touched travis and I don't understand what is going on after a cursory look... maybe rjo ?
<sb0> whitequark, the compiler has to work on windows... /dev/fd/xxx will be problematic
<whitequark> well
<sb0> also, python threads are meh...
<whitequark> they are well-fit for this one task, which is waiting on I/O
<whitequark> however
<cr1901_modern> well, msys2 provides /dev/fd, but I suspect it's very limited
<whitequark> I've spent last 20 minutes trying to make python not set O_CLOEXEC
<whitequark> so fuck it
<sb0> PIC is difficult ...
<whitequark> PIC?
<sb0> position independent code, as opposed to the current (and working) code that uses a relocatable object and has none of those problems
<cr1901_modern> Ya know, why do we even HAVE relocation/PIC when virtual memory solves that problem as a side effect?
<whitequark> wat?
<sb0> there's no virtual memory on the device and it doesn't solve it anyway
<whitequark> PIC is not very meaningful without virtual memory
<cr1901_modern> sb0 answered my q, but...
<whitequark> I'm using a linker so that I a) have to deal with less relocations b) it will build .eh_frame_hdr
<whitequark> which nicely integrates with libunwind
<cr1901_modern> Relocation fixups addresses so programs can be placed anywhere. OSes with virtual memory completely undo that by ensuring that all programs have the same entry point from the program's POV.
<cr1901_modern> in any case, I'm just thinking out loud
<whitequark> 1) ASLR 2) shared libraries
<rjo> sb0: i would go for Constant (subclass of Value) and recommending (by convention/coding guidelines) that as something to be passed around. i would not depecate []. fslice(s, slice(a, b, c)) is so much less readable than s[a:b:c] that it outweighs the consistency benefit.
<sb0> what about C and removing integers?
<rjo> and i think there has never been a promise that only "digestible" verilog is produced.
<sb0> well, correct verilog guaranteed would be nice. people run into the occasional annoying buggy corner case from time to time ...
<rjo> whitequark: could you "mv lit-test test/lit"?
<whitequark> test/lit/test/...
<sb0> many of those corner cases require complicated code to fix, unfortunately
<whitequark> plus it's not in the usual format. But sure, if you really think it's necessary
<rjo> but migen does not want to catch circular references for example.
<sb0> circular references?
<rjo> sb0: C() and removing integers is a bit harsh imho. but yeah well.
<rjo> a.eq(b), b.eq(~a). or even a.eq(~a).
<rjo> in comb
<sb0> ah, unstable comb loops
<sb0> they're valid verilog
<rjo> but not digestible.
<rjo> which is the relevant parameter imho.
<rjo> generating technically valid verilog and not being able to do anything with it is close to useless imho.
<rjo> so i would just forget about working around all corner cases that make ise/vivado/quartus stumble.
<sb0> ok, but those originate from a bug in the design
<sb0> whereas C(16)[1:2] is legit, but verilog compilers will choke on the generated code I think
<cr1901_modern> Has the Cat() bug popped up in Artiq yet?
<sb0> no because all those corner cases can actually be easily avoided manually
<rjo> slicing lhs Cat?
<cr1901_modern> Yes, that's a better name lol
<cr1901_modern> It's valid in Migen (and kinda logical, IMO), but Verilog chokes on it
<rjo> in general a Signal().proxy() method would be nice for these things. Also Array() could use it.
<cr1901_modern> Signal().proxy()?
<rjo> sb0, whitequark: we need a bit more people to understand the CI stuff than just Yann (vacation) and me. And you guys broke it. IMHO you are very capable of fixing it.
<whitequark> I have absolutely no idea what happened to it, that's why I'm asking
<rjo> cr1901_modern: gives you a proxy signal that you can lhs-slice.
<rjo> whitequark: your llvm/binutils changes happened, no?
<cr1901_modern> Well, THAT would've been nice to know last month lol
<whitequark> rjo: I haven't touched migen.
<whitequark> in fact, I haven't touched any Python there when it broke
<whitequark> which is why I'm so confused about it.
<rjo> i bet you can reproduce it locally. the stuff should be runnable locally and does not need root.
<whitequark> hrm
<rjo> i don't have magic dust and don't see the bug after having a had a cursory look either. so i would do the same.
<whitequark> i suppose
<GitHub47> [artiq] whitequark pushed 2 new commits to new-py2llvm: http://git.io/vYbhg
<GitHub47> artiq/new-py2llvm 2cd25f8 whitequark: Rename artiq.compiler.testbench.{module → signature}.
<GitHub47> artiq/new-py2llvm e8c1079 whitequark: Implement shared object linking.
<rjo> whitequark: you are messing with path. i suspect you are putting the system python interpreter ahead in https://github.com/m-labs/artiq/blob/master/.travis/get-toolchain.sh#L25 because the environment is activated (changing PATH again) only later.
<whitequark> ohhhh.
<whitequark> and you said you didn't have magic dust.
<rjo> just a 50% suspicion.
<rjo> i also suspect you could actually install your tarballs as conda packages directly and skip all that (conda will handle your path).
<rjo> whitequark: when did you discover unicode arrows?
<GitHub167> [artiq] jordens pushed 1 new commit to master: http://git.io/vYNUa
<GitHub167> artiq/master 55708e8 Robert Jordens: pipistrello: drop bitgen_opt change (done upstream)
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#355 (master - 55708e8 : Robert Jordens): The build has errored.
travis-ci has left #m-labs [#m-labs]
<whitequark> rjo: had them in my ~/.XCompose for a long time
<whitequark> along with <Compose> <t> <f> (╯°□°)╯︵ ┻━┻
<rjo> you must feel very disappointed that -- while you can map all kinds of shapes -- there is are no unicode modifiers for color.
<whitequark> there actually are.
<whitequark> well, skin color modifiers for emoji, but still, there are.
<rjo> good lord. how racist.
<whitequark> ?
<rjo> but color in unicode would have really smart. then all those escape sequences can finally go (in 500 years)
<rjo> there is no red, yellow etc.
<rjo> it is just a one-dimensional scale from a light "kaukasian" (as the americans call it) to a dark brownish tone.
<whitequark> ah. I suppose
<rjo> "the Fitzpatrick scale"
<whitequark> speaking of color, you could treat 256-color escape sequences as such
<whitequark> unambiguous (there's only one way to encode those as far as I know), and valid Unicode too.
<rjo> ah no. it gets better: "When a human emoji is not immediately followed by a emoji modifier character, it should use a generic, non-realistic skin tone, such as:" and here it comes: blue
<whitequark> imo the only good thing about emoji is that you can finally block them all in a uniform way
<rjo> but iirc the palette is not defined.
<cr1901_modern> Can't wait for *nix kernel terminal drivers to support Unicode emoji
<whitequark> was harder when every website used images or such.
<whitequark> ah right. the palette isn't.
<rjo> yeah. and logging.DEBUG == "
<rjo> that broke.
<rjo> U+1F913 NERD FACE
<whitequark> ...
<cr1901_modern> That would be a very valid use of kernel dev's time.
<rjo> you have to factor in that U+1F913 uses less screen space than "[DEBUG]" and is quicker to understand.
<whitequark> is there a python benchmark library that *works*?
<cr1901_modern> What's wrong with the built-in profiler?
<whitequark> which one?
<cr1901_modern> The only one I've used. I know that's not helpful, so I'll see if I can't figure out which one I used. XD
<cr1901_modern> I think I just used the raw Python profiler
<cr1901_modern> "The profiler modules are designed to provide an execution profile for a given program, not for benchmarking purposes"... oh.
<cr1901_modern> They subsequently mention timeit, which I assume you used and it didn't suit your needs
<GitHub95> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNCx
<GitHub95> artiq/new-py2llvm 3b5d3e2 whitequark: Add a performance measurement testbench.
<rjo> timeit and cProfile are nice. ipython makes them really convenient.
<whitequark> so, for lit-test/test/integration/arithmetics.py, which is quite heavy on branchs
<whitequark> 11 ARTIQ typechecking and transforms runs: 5.34s, 485.54ms/run
<whitequark> 21 LLVM optimization and linking runs: 5.25s, 249.90ms/run
<GitHub176> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNBu
<GitHub176> artiq/new-py2llvm 6d8d0ff whitequark: Update performance testbench to include time spent in ARTIQ.
* rjo twitches
<whitequark> a release (even lto) build of LLVM without assertions will be much faster, but I won't be the the one who builds it today
<whitequark> and assuming the types of kernel parameters don't change, we can skip ARTIQ typechecking/transforms most of the time when modifying those
<whitequark> but this should be the ballpark
<rjo> >10ms per line of assert. gulp.
<whitequark> oh dear god
<whitequark> I have this code that assigns names to IR instructions that's quadratic
<whitequark> 79 ARTIQ typechecking and transforms runs: 5.04s, 63.79ms/run
<GitHub157> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNuO
<GitHub157> artiq/new-py2llvm d7f9af4 whitequark: Fix accidentally quadratic code in compiler.ir.Function._add_name.
<cr1901_modern> whitequark: Is the quadratic part that the while name in... always run, while the "typical" case is to just add a new name (I'm just seeing if I understand)?
<whitequark> no, that if you repeatedly add the same name, it takes one more step to generate an unique one every time
<whitequark> or maybe yes, depending on what you mean exactly
<cr1901_modern> Nah, I misunderstood it the algorithm. :P If I don't understand something you/others say in this room, I try to see if I can figure it out for myself. Then ask if the room's quiet or leave it for another time.
<cr1901_modern> I forgot that https://en.wikipedia.org/wiki/1_%2B_2_%2B_3_%2B_4_%2B_⋯ has a quadratic closed form solution
<cr1901_modern> that's why I was having trouble with this o.0;
<whitequark> llvmlite is amazing!
<whitequark> in the sense that the profile has:
<whitequark> 79590/58305 0.109 0.000 0.701 0.000 {built-in method print}
<whitequark> and
<whitequark> 162930/124665 0.189 0.000 0.300 0.000 {method 'format' of 'str' objects}
<whitequark> of course, the *real* issue is that calling into LLVM C API is even slower
<whitequark> none of the above would be a problem if python had a real runtime and not some rudiment from 1995
<whitequark> like, for example, JVM.
<whitequark> anyway, most of the time ARTIQ wastes is spent in the parser, which is good, because it's trivially cacheable. just have a dict of sha1(code)->AST
<GitHub32> [artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vYNdH
<GitHub32> artiq/new-py2llvm b0185f3 whitequark: Add profiling to the performance testbench.
<cr1901_modern> How long was the full test (at least .701, but am curious about ratios)?
<whitequark> 5s
<whitequark> 2/5 is spent inside LLVM
<whitequark> the rest, mostly concatenating strings
<cr1901_modern> I agree that Python isn't exceptionally fast, but what's wrong with it's C FFI such that'll push that ratio up?
<whitequark> I dunno, actually
<whitequark> but I doubt numba people would just go and rewrite it from scratch if it was easily fixable
<cr1901_modern> FOSS is about choice in Python FFI bindings
<whitequark> ohhhhh i see
<whitequark> llvmpy has some kind of extremely generic wrapper around C++ memory management, that allows it to wrap much of LLVM's innards
<whitequark> if it used the C API, this would probably not have been a problem on python.
<rjo> whitequark: ack to speed. llvmlite is merely a templating engine.
<whitequark> well, the IR parts of llvmlite.
<whitequark> thankfully it does not require me to shell out to optimize or codegen.
<whitequark> I'd say "redo it via the C API" but the C API has usability issues. it tends to segfault if you use it wrong, or in best case, give you an unhelpful backtrace that doesn't mention Python function names
<whitequark> so there's some truth to emitting LLVM IR assembly and re-parsing. but, slow.
<cr1901_modern> And according to the llvmlite page, some functionality just isn't possible with the C API. Tbh the profiling numbers whitequark pasted earlier don't SEEM that bad to me.
<cr1901_modern> But I'm not working on Artiq, so I'm prob missing someting
<whitequark> imagine a 500-line file taking up to 10 seconds to compile
<whitequark> ("amount of lines" is an extremely bad measure of complexity, so i'm assuming it will be some fairly contrived code.)
<cr1901_modern> Well, most ppl would get impatient/think there's something wrong
<whitequark> sb0: so I am looking at the compilation model that old py2llvm had
<whitequark> do I understand correctly that such things as drivers were pulled in by the compiler, i.e. if you do self.dds.init, it looks up the method, sees that it has @kernel, and proceeds to also compile it?
ylamarre1 has quit [Quit: ylamarre1]
<rjo> yes and inline it.
<whitequark> *always* inline? that seems odd
<whitequark> anyway, the nature of my question was... the current compilation model is designed much like python's
<whitequark> you get a module, which corresponds to a single LLVM translation unit, and within a module all types should be known
<whitequark> I'm currently pondering whether it maps well to what ARTIQ does
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 244 seconds]
<rjo> currently it is always inlined. but it should be left to llvm to decide that in most cases.