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_ has joined #m-labs
sb0 has quit [Ping timeout: 265 seconds]
mumptai has quit [Remote host closed the connection]
<rjo>
whitequark: fancy!
<rjo>
sb0: Packet loss only under high traffic/flood situation or also idle?
sb0_ has quit [Ping timeout: 246 seconds]
mumptai has joined #m-labs
<cr1901_modern>
whitequark: "a closure is just a mutable record packed inside a function" What IS a record?
<whitequark>
cr1901_modern: what?
<whitequark>
a set of fields
<cr1901_modern>
I don't remember what compelled me to ask that question, sorry.
nicksydney has quit [Remote host closed the connection]
<cr1901_modern>
Rereading what you said, I don't see where I was confused anymore o.0;
<cr1901_modern>
whitequark: re: the mutable part... well TIL that closures can INDEED mutate their environment lol: https://gist.github.com/cr1901/c6d11e084dd8338d80a2 Wouldn't this be impossible without GC, as sb0 asked earlier? >>
<cr1901_modern>
Or at the very least, impossible to implement with traditional stack/register based autos?
<whitequark>
you just can't let the closure escape its place of definition
sb0 has joined #m-labs
<cr1901_modern>
In the gist linked above, that would mean I'm only able to use "the lambda defined in my_closure" within "my_closure", correct?
<whitequark>
yes
<whitequark>
this is a simplified form of the region system, used in cyclone and rust
<whitequark>
simplified, because i ain't got time to implement it in full
<cr1901_modern>
lol I'm starting to appreciate that... Is what I described (using lambda only within my_closure) any different from nested functions?
<whitequark>
lambda still has full access to environment
<cr1901_modern>
Alright, makes sense. Thanks!
<cr1901_modern>
sb0: Sent a corrected patch finally. Only 5 days late lol.
<sb0>
whitequark, oh, so it's not a "real" closure, i.e. the function creating the closure cannot return it, only call it?
<whitequark>
sb0: well, it's a real closure
<whitequark>
or alternatively, there is no "real" mutable data :)
<whitequark>
but yes, it cannot escape, neither can a list
<sb0>
whitequark, btw I suppose you are rewriting the exception handling?
<sb0>
in the compiler
<whitequark>
oh
<whitequark>
I was *certain* I forgot about something
<sb0>
how far are you with code generation?
<whitequark>
no code generation right now. I'm working on the region system right now, actually
<whitequark>
(the non-escaping mutable data thing)
<whitequark>
the plan is to add regions (nearly done), typing for EH (fortunately, typing is not complex here), then look at the best way of implementing codegen
<sb0>
there is a somewhat annoying bug with the exception parameters right now, and I wonder if it makes sense that I fix it myself in the current code or if you are going to rewrite that anyway
<whitequark>
can you describe it?
<whitequark>
speaking of EH. do you plan to use EH for control flow here?
<whitequark>
if no, I will go with libunwind (C++-style zero-cost exception handling)
<whitequark>
if yes, a different approach would be necessary
<whitequark>
there's a clever trick in OCaml that can be used to avoid costly sjlj invocations, but it needs to be done early in the design...
<sb0>
the problem with all those tricks is that they take lots of development time ...
<sb0>
right now it's doing lots of sjlj, and that would be fine I believe
<sb0>
what do you mean by using EH for control flow?
<whitequark>
it just means you can't execute anything while unwinding
<whitequark>
in fact, it's much simpler than libunwind
<whitequark>
ah, I see the bug. I was thinking about that just now
<whitequark>
yes, it will be fixed
<sb0>
I don't think people will use exceptions all that much, so the pragmatic thing to do is implement the mechanism that takes the least development time
<whitequark>
ok. I will look whether libunwind can be easily integrated, and if not, it's back to sjlj
<sb0>
sjlj is already pretty much debugged and doesn't behave funny on the hardware
<whitequark>
the nice thing about libunwind is how the C++-style EH integrate nicely with LLVM and gdb
<whitequark>
e.g. you get real backtraces even after inlining
<whitequark>
and of course the zero-cost common path
<sb0>
doesn't the linker need to process the eh sections for that?
<whitequark>
the linker doesn't inline, unless you use LTO, in which case "there is no linker"
<sb0>
since we're not using the fancy features right now, it can be nice and small
<whitequark>
yes, there would also be relocations in DWARF if you're producing a relocatable file
<whitequark>
I don't think there are any new kinds of relocations specific for DWARF
<whitequark>
it's just REL/RELA
<whitequark>
the most tricky part would be teaching libunwind about the ABI used by the code
<whitequark>
the rest should just work
<sb0>
and wondering for a few days/weeks why the hardware just freezes/crashes/corrupts its memory when executing a certain mess of code that uses exceptions in a dozen places
<whitequark>
does it have JTAG on the CPU?
<whitequark>
oh, speaking of hardware, I really need to get that pipistrello...
<cr1901_modern>
What boards do you have? I need to get a Spartan-6 board at some point.
<cr1901_modern>
Also, "There is no linker?" (or is that at least partial hyperbole?)
<sb0>
no, it doesn't
<whitequark>
cr1901_modern: with LTO, the job of the static linker is reduced to producing the final executable from a relocatable
<whitequark>
which... mostly means updating a few headers
<whitequark>
the rest is done by LLVM, combining bitcode fields (or by gcc, combining its RTL files, or...)
<sb0>
so a good strategy is not to make things more complicated than they absolutely need to be ...
<whitequark>
sb0: ok, yes, without JTAG that would be annoying to debug
<whitequark>
not to mention you can't actually use GDB
<whitequark>
I agree, sjlj is the way to go
<sb0>
lwip is already doing an excellent job at producing obscure bugs that piss me off
<whitequark>
heh
<whitequark>
can we add JTAG?
<whitequark>
(re SJLJ, I'll probably generate invoke instructions and let LLVM lower it to sjlj, anyway)
<sb0>
btw, last time I checked the llvm sjlj intrinsics for or1k were broken, so I recommend you use the direct calls as I do
<whitequark>
ah, crap
<whitequark>
are you sure the intrinsics were *broken*? they have behavior that differs from real sjlj
<sb0>
no, I'm not sure
<whitequark>
ok, I will keep in mind
<sb0>
also, we need interop with C as the runtime also needs to raise exceptions
<sb0>
so I didn't give the llvm sjlj stuff much thought when it started behaving funny
<whitequark>
it's not incompatible with C...
<whitequark>
you can even use it from C with some obscure GCC extension syntax
<whitequark>
(yes, I remember the C code is not built with LLVM)
<sb0>
why use all the obscure stuff anyway?
<whitequark>
invoke instructions provide more information to the optimizer than direct invocation of sjlj
<sb0>
given how little people will use exception, I believe that optimizing the crap out of them isn't the smartest way to spend development time right now
<whitequark>
ok
<cr1901_modern>
I've never actually used LTO- I just know OF it. I didn't learn until 5 minutes ago that LTO- at least as implemented in GCC- requires dumping all compiled translation units into a single file.
<cr1901_modern>
Now the "there's no linker" statement makes sense- there's only a single object file to go through.
<whitequark>
it doesn't
<whitequark>
you get different .o files and .a as well, it looks just like a regular compilation
<whitequark>
but the content of these .o files is not an ELF relocatable but dumped compiler IR
<whitequark>
what I meant is that the system linker only sees a single relocatable file, ever
<whitequark>
(maybe also crt0, though you'd want to inline that too, why not)
<whitequark>
it produces some interesting results, such as LLVM bitcode gaining some of the functionality of ldscripts, such as appending sections
<cr1901_modern>
Presumably that single relocatable file is generated from the compiler IR, which in turn is converted (i.e. ELF object => ELF exe) to the final executable?
<whitequark>
yes
<whitequark>
really, the only reason LLVM depends on the system binutils at all is that it can't interpret an ldscript
<whitequark>
once LLD gains ldscript support, you could make a toolchain that can be retargeted to any platform at all
<whitequark>
with a single switch
<whitequark>
you can already generate code, just not executable.
<cr1901_modern>
Well "for any arch that LLVM supports, you can generate an exe with any memory map" :P
<whitequark>
well, yes, you need a libc
<whitequark>
or at least a set of syscalls, assuming you abohor C
<whitequark>
*abhor
<cr1901_modern>
I'll never abhor C, but I acknowledge after enough twitter arguments with you that it has problems/probably should've never been forced into the role it has.
<cr1901_modern>
In theory, GCC can generate data and code segments with arbitrary segments as well (beyond the traditional Unix ones). I'm not sure if LLVM allows you to do the same.
<whitequark>
segments?
<cr1901_modern>
".text .bss .data as assembly directives converted to whatever ELF calls them"
<whitequark>
sections
<whitequark>
and yes, LLVM can place objects into arbitrary sections, of course
<cr1901_modern>
Do you know if ELF loaders in practice support arbitrary sections, however (again, beyond the traditional ones that are generated by GCC/LLVM)?
<whitequark>
ELF loaders don't care about sections at all
<whitequark>
ELF loaders just map the PT_LOAD segments into memory
<whitequark>
and relocate them
<whitequark>
an ELF loader is quite dumb
<whitequark>
it's like 100 lines of C if you don't care about relocations, and 200 if you do
<cr1901_modern>
Huh... interesting. Just wanted to know if it was possible to take advantage of arbitrary sections in practice :P.
<cr1901_modern>
Btw, what CAN LLD do right now if it doesn't support ldscripts?
<whitequark>
sure, toolchains routinely use custom sections
<whitequark>
LLD supports ldscripts, just not as well as ld or gold yet
<whitequark>
when it did not at all, it could still merge relocatables
<cr1901_modern>
Well, that's better than nothing lol. "-ffunction-sections" is very interesting, didn't know about it. It reminds me of the old DOS large memory model, where each translation unit's code is put into it's own code section/segment.
<whitequark>
has nothing to do with that
<whitequark>
ideally a linker would work on atoms (i.e. symbols with associated contiguous blocks of data) directly, but compatibility reasons dictate that atoms have to be grouped
<whitequark>
LLD actually used to work with atoms, but that didn't go well with reality
<cr1901_modern>
In other words, anything that doesn't fit the ".text, .data, .bss" granularity doesn't fit reality. :/
<whitequark>
no one said this
<cr1901_modern>
What other compatibility reasons are there for atoms to be grouped though? That was the "obvious" one I was thinking of.
<cr1901_modern>
Well, splitting the linker into different models (Unix, MachO) seems like an interesting way around the problem. It also gives the ability to add other models (or "use the best match") for esoteric obj/exe formats.
key2 has joined #m-labs
<GitHub157>
[migen] sbourdeauducq pushed 1 new commit to master: http://git.io/vtzwZ
<sb0>
cr1901_modern, you didn't actually change anything regarding the programmer parameter and your email is not clear. send another patch if you meant to remove it...
travis-ci has joined #m-labs
<travis-ci>
m-labs/migen#47 (master - 3ea7ef8 : William D. Jones): The build passed.
<ysionneau>
yes I saw that, it's hard to understand why ... I double checked and I didn't find any faulty test that would use the "default loop" instead of creating another or something like that
<ysionneau>
very weird ...
mumptai has quit [Remote host closed the connection]
<GitHub161>
[artiq] whitequark pushed 3 new commits to new-py2llvm: http://git.io/vt20K
<GitHub161>
artiq/new-py2llvm 9044e88 whitequark: Elaborate hierarchy of builtins.