Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-06-09

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:16 cognominal joined #moarvm
01:08 btyler joined #moarvm
01:26 FROGGS_ joined #moarvm
03:38 btyler joined #moarvm
05:31 woosley joined #moarvm
05:35 odc joined #moarvm
07:05 zakharyas joined #moarvm
07:41 nwc10 jnthn: still not broken.
07:46 masak <jnthn> nwc10: Well, the reason you don't see all the breakage is that the inline stuff isn't actually turned on yet...I've got a local change here that does that.
07:46 brrt joined #moarvm
07:46 nwc10 masak: < jnthn> Well, yeah, but collateral damage is also possible.
07:47 nwc10 :-)
07:47 masak ah :)
07:55 brrt morning folks
07:56 FROGGS morning
08:09 jnthn morning o/
08:10 FROGGS morning jnthn
08:12 lue joined #moarvm
08:34 FROGGS[mobile] joined #moarvm
08:50 FROGGS[mobile]2 joined #moarvm
08:55 dalek MoarVM/moar-jit: 5a27f9b | (Bart Wiegmans)++ | src/ (9 files):
08:55 dalek MoarVM/moar-jit: Preliminary jit graph compilation.
08:55 dalek MoarVM/moar-jit:
08:55 dalek MoarVM/moar-jit: This doesn't actually compile anything useful, however it will
08:55 dalek MoarVM/moar-jit: construct a proper function prologue and epilogue.  I've also
08:55 dalek MoarVM/moar-jit: changed the platform 'mmap' functions so that I can use them -
08:55 dalek MoarVM/moar-jit: they weren't used before.
08:55 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/5a27f9bf0d
08:59 brrt morning jnthn
09:06 Util joined #moarvm
09:06 brrt ok, the way i see it, there are at least 4 different spaces from which values can come, and perhaps more if i list them now
09:07 brrt 1 - the 'jit' frame - i.e. the stack space that holds (in my case) the threadcontext and the frame
09:07 brrt 2 - the 'work' registers - i.e the usual moarvm work space
09:07 brrt 3 - lexicals
09:08 brrt 4 - constants / literals
09:08 brrt i'm forgetting quite a few
09:17 masak don't need an exhaustive list to get something simple/working off the ground...
09:20 brrt i suppose not
09:24 synopsebot joined #moarvm
09:42 jnthn 5 - returned from C functions you mgiht call that implement VM-internal things.
09:43 jnthn Also there's incoming args.
09:43 brrt oh, thats a good one
09:44 brrt on x86_64, a return is always in rax
09:44 * brrt wonders what happens when you return a struct
09:47 nwc10 brrt: find the API docs, but a typical C approach is that the function takes a hidden first argument, which is a pointer to memory where the return value is to be written
09:47 nwc10 er, ABI docs
09:47 brrt hmmm.. i recall reading that
09:47 vendethiel joined #moarvm
09:47 brrt i'm going to see what gcc / clang does
09:50 nwc10 oh, IIRC, one interesting gothca of the x86_64 ABI is that variable arguments functions are called with one CPU register set to contain the number of arguments passed in CPU registers
09:51 nwc10 with the upshot that if you call a varargs function from a call site that didn't know that it was a varargs function, that register is not set up, and the callee may have a jump table that assumes that it *is*
09:51 nwc10 even though you are calling with a(n otherwise) sane sequence of arguments)
09:51 brrt i know, i tried printf and it burned me in just that way
09:51 brrt :-)
09:52 brrt also because i had the printf function in the rax register
09:52 brrt (long, dynasm specific story, not very interesting)
09:52 brrt and the rax register is where the number of varargs are held
09:52 nwc10 I didn't know this. I found it out the hard way
09:52 nwc10 (why is this C code crashing, once I try to write a test for it)
09:54 brrt http://en.wikipedia.org/wiki/X86_calling_conventions is a pretty reasonable reference
10:17 brrt &lunch
11:03 FROGGS joined #moarvm
11:08 brrt joined #moarvm
11:08 brrt ok, mike pall says dynamic registers on x64 are broken
11:08 brrt that is... a pain
11:08 brrt but its ok i guess
11:14 timotimo "dynamic registers"?
11:15 timotimo is that "x86_64 sucks and the feature 'dynamic registers' it offers is pretty much useless"?
11:18 brrt ehm... its more subtle than that
11:18 brrt there is  - afaik - a register renaming feature in (some) x86_64, but thats not what i mean :-) and its not 'public' either, i think
11:19 brrt i mean the dynasm feature that has you refer to a register by number
11:20 brrt and that doesn't work on any other platform than x86, including x86_64, because - i'm paraphrasing - register encoding is hard
11:20 brrt i.e. encoding where the results of a register go to
11:21 brrt that, though, can be interpreted as 'x86 / x64 is suboptimal', but that shouldn't surprise anyone :-)
11:22 timotimo oh, crap :(
11:24 brrt yes, well the alternative is writing a huge switch clause
11:33 timotimo :|
11:35 FROGGS joined #moarvm
12:11 colomon joined #moarvm
12:33 jnap joined #moarvm
12:35 * brrt afk
12:41 harrow joined #moarvm
12:47 brrt joined #moarvm
12:47 * brrt back
12:49 jnthn to the future
12:51 brrt :-D
12:51 * brrt is off writing his huge switch tables
12:52 jnthn Bet you don't beat interp.c's one :P
12:54 brrt maybe not
12:54 brrt but i'll get close :-P
12:56 brrt or, to put it in other words
12:56 brrt have any clever way of creating a 16x16 jump table as a #define statement
12:57 jnthn Does it have to be a jump table? Can't do it with a static array?
12:58 brrt i'll explain the challenge in full, maybe you see something clever
12:59 brrt basically, i need to compile an add instruction, right?
12:59 brrt (this is going to sound more convoluted than it really is)
12:59 jnthn .oO( addition...so complex :D )
12:59 brrt ok, i need at least one of the add instructions to be a register
13:00 brrt which register should that be? well, don't care at this point, any register
13:00 jnthn You mean operands?
13:00 brrt yes, operands :-)
13:02 brrt hmmm
13:02 brrt ok, still haven't explained it huh
13:02 brrt :-)
13:02 brrt basically, i want something like emit_op(op, reg1, reg2)
13:03 jnthn Are we talking about MoarVM registers or CPU ones at this point?
13:03 brrt cpu registers
13:03 brrt :-)
13:03 jnthn ok.
13:03 brrt ok, for that to work, i need to have dasm say something like | op reg1, reg2
13:04 brrt but as i see it now, thats not actually possible with a c-preprocessor macro
13:04 brrt because dynasm runs before cpp does
13:04 jnthn The issue being you have to know *which* reg?
13:05 colomon joined #moarvm
13:06 jnthn What if you invert the problem? "To JIT an add, the operands need to be in X and Y"
13:06 brrt no, the issue being i know which reg, but not being very willing to write a nested 16x16 switch everywhere i want to write an op with dynamic register
13:07 brrt that is possible, but that is pretty slow
13:07 jnthn Yeah, that sounds wrong
13:08 jnthn Well, you say pretty slow, but remember that initially it's really important to keep ->work in the same shape that the interpreter would.
13:08 jnthn I really don't think we should start cheating on that until we have it working that way.
13:08 brrt true
13:08 brrt hmmm
13:08 brrt ok, i guess i could get away with static register allocations for now
13:10 jnthn It's really important that we can deopt. I'd wager that the speculative optimization we gain the ability to do by knowing we can always deopt will by a good bit outweigh the costs of keeping the callframe in shape for now. And later on when it all works, we can use the fact that we statically know our de-opt points to start cheating.
13:11 jnthn And the speculative ops allow us to turn nqp::getattr into cheap pointer operations without any kind of calling.
13:11 brrt it is also (much) simpler for me to emit static register accesses now
13:11 jnthn *speculative opts
13:11 jnthn And inline, and so forth.
13:11 jnthn Yes, I think so :)
13:11 brrt but its' not where i want to go :-)
13:12 brrt i'll put it into the long-term-goals for now
13:12 jnthn I don't think going the static way now will make it impossible to go the other way later.
13:12 brrt no, of course not
13:13 jnthn But it will means we get a viable JIT sooner. :)
13:13 jnthn *mean
13:13 brrt it means i can go ahead now
13:13 brrt :-)
13:14 jnthn aye
13:14 vendethiel joined #moarvm
13:41 nwc10 erk. this isn't right. I'm 20% last month: https://www.ohloh.net/p/moarvm/contributors/summary
13:48 nebuchadnezzar hello
13:49 nebuchadnezzar Is there a way to make the libdir target configurable?
13:49 nebuchadnezzar something like --libdir=<path to lib>
13:49 nebuchadnezzar I'll need to patch build/setup.pm to support MultiArch otherwise ;-)
13:50 donaldh joined #moarvm
13:50 donaldh left #moarvm
13:51 FROGGS MoarVM itself only cares about --prefix
13:52 nebuchadnezzar yes, the lib is put under @prefix@/lib, for MultiArch I need to change the /lib to /lib/<triplet>
13:53 FROGGS then we need to adjust setup.pm, yes
13:54 nebuchadnezzar I'll fill a request on github for this, work on a Debian specific patch and submit it if it works
13:55 nebuchadnezzar I support Configure.pl must be changed to handle the new --libdir option?
13:57 jnthn Sounds reasonable.
13:57 FROGGS is that about /lib only? I mean, /include can be left untouched?
13:59 nebuchadnezzar FROGGS: yes, /include files are shared accross architectures
13:59 FROGGS k
14:00 nebuchadnezzar I wonder if touching build/setup.pm is required since Configure.pl could be sufficient
14:00 FROGGS then a --libdir that defaults to 'lib' sounds right
14:05 nebuchadnezzar I had a message from lintian about the use of RPATH: http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html
14:06 nebuchadnezzar I made a little Debian patch to remove it http://paste.debian.net/104110/
14:07 * brrt off again
14:07 brrt left #moarvm
15:14 cognominal joined #moarvm
16:40 FROGGS joined #moarvm
18:04 timotimo jnthn: anything more coming out of you tonight? i'm probably going to cook some dinner now and then start writing the weekly
18:04 jnthn yeah, I'm doing last bit of $dayjob stuff I wnated to get through today
18:04 jnthn and then will hack inline some more
18:04 timotimo also, it'd be good to know where the first spot is where we hit the missing deopt things in the inliner
18:07 nwc10 nebuchadnezzar: I believe that the history of MoarVM's configuration system is "get it working", and nothing more sophisticated than that. So, basically, if it's doing anything that makes it hard to package for Debian (or any other Linux, or any other *nix), then I believe that there's no reason to assume that it has to stay the way that it is, and the packager work round it.
18:08 nwc10 hence patches that change to code because "it would be easier if we could do this instead" or "it would be easier if we could do this as well" are welcome.
18:09 nwc10 (as ever, I can't guarantee you that they'll be applied, because of $reason that wasn't obvious ahead of time, but you are most definately not wasting your time by proposing things to change that make your life easier)
18:09 jnthn What nwc10 said
18:09 jnthn timotimo: Not sure the latest blocker is deopt any more...
18:09 jnthn Though bits of it are still missing
18:09 nwc10 also, I think that currently we have access to most platforms and variants that MoarVM has ever been confirmed as building on, so we can do reasonably exhaustive tests of "did this actually mess something else up completely"
18:10 nwc10 so fairly major refactoring isn't ruled out, if that turns out to be the easiest way to get Debian packaging in good shape for the next decade
18:25 timotimo jnthn: do we already get through a setting compilation?
18:26 jnthn timotimo: We don't get through NQP startup :P
18:26 nwc10 branch as committed (without his local evil) looks like it will complete the spectest
18:26 jnthn Right
18:27 jnthn You need to turn-on patch here to actually make it erupt.
18:28 brrt joined #moarvm
18:30 nwc10 spectest is consistent with MoarVM master under ASAN.
18:30 nwc10 so "we have normality, I repeat, we have normality" and "anything you can't deal with is therefore your own problem"
18:48 timotimo jnthn: argh
18:49 jnthn timotimo: uh, that's not actually true
18:49 jnthn timotimo: We surive startup fine. We don't survive parsing much because it starts inlining, say, CAPS into CAPHASH
18:52 japhb_ If inlining is good, inlining more must be better, right?
18:52 timotimo oh, hehe.
18:53 timotimo though i'm not sure why it's bad to inline CAPS into CAPHASH
18:54 jnthn It's *fine* to do so
18:54 timotimo unless you're doing it wrong? :)
18:54 jnthn It's just that at some point CAPHASH does and deopts.
18:54 jnthn Though that is OK too for now...
18:54 timotimo ah, that makes sense
18:54 jnthn I think the problem may be more that I didn't start GC-marking locals and lexicals that got inlined.
18:54 timotimo oh!
18:54 timotimo that's cute :)
18:55 timotimo ticking time bomb etc etc
18:55 jnthn And the last issue I got was a SEGV with a bad pointer
18:55 jnthn So that's my next thing to tend to :)
18:55 timotimo the pointer itself was bad?
18:55 jnthn Looked like
18:55 timotimo maybe setting the "set old nursery spaces dont-read-dont-write" thing again would help?
18:55 jnthn Well, looked like a pointer that was once legit, but now is pointing at junk
18:55 jnthn Well, let me put in the fix for the thing I *know* is broken before doing real debugging :)
19:01 timotimo ah, i thought maybe it was a pointer that wasn't even aligned or something
19:19 FROGGS[mobile] joined #moarvm
19:27 [Coke] moar is now the only clean spectesting rakudo.
19:29 jnthn Time to write moar tests
19:29 masak :P
19:30 cognominal joined #moarvm
19:35 [Coke] fix the ones that are still borking! ;)
19:35 [Coke] (for other rakudos‚
19:56 FROGGS joined #moarvm
20:38 raiph joined #moarvm
20:42 dalek MoarVM/inline: b445462 | jnthn++ | src/spesh/ (5 files):
20:42 dalek MoarVM/inline: Build up inline-aware local/lexical type maps.
20:42 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/b445462cfc
20:43 brrt i have a bug on my screen :-D
20:43 brrt a literal bug
20:44 brrt and its off again
20:45 dalek MoarVM/moar-jit: d94b314 | (Bart Wiegmans)++ | src/ (6 files):
20:45 dalek MoarVM/moar-jit: Naive per-instruction compilation of a few opcodes.
20:45 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d94b314ee9
20:45 dalek MoarVM/moar-jit: 476ccc2 | (Bart Wiegmans)++ | src/jit/x86_64. (2 files):
20:45 dalek MoarVM/moar-jit: Added argument setup for c calls.
20:45 dalek MoarVM/moar-jit:
20:45 dalek MoarVM/moar-jit: This works only for the first three arguments- fourth argument
20:45 dalek MoarVM/moar-jit: would overwrite our work pointer - and only for integers.
20:45 dalek MoarVM/moar-jit: Still, should be enough to call a few MVM internal functions.
20:45 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/476ccc2d6d
20:45 FROGGS O.o
20:46 brrt also known as - the commits that deleted MVMJitGraph
20:47 tadzik fun :)
20:48 brrt well,..... i'm not so terribly happy with it all
20:48 brrt i'll  be blogging about it
20:49 raiph brrt++ # commits
20:50 raiph ++brrt # blog
20:50 brrt ahead of time eh? :-)
20:52 jnthn brrt++ # progress
20:53 jnthn Turns out we didn't even do a GC run at the point things explode, so it's probably an uninline bug.
21:06 nwc10 jnthn: b445462cfce2b67e4ac98f66bcfec62abc7cf925 not broken
21:19 donaldh joined #moarvm
21:45 jnap joined #moarvm
22:02 brrt jnthn -> http://brrt-to-the-future.blogspot.nl/2014/06/news.html :-)
22:02 brrt your advice greatly appreciated
22:03 * brrt &sleep
22:04 brrt left #moarvm
22:04 FROGGS gnight brrt
22:26 timotimo brrt: doesn't sound very happy :(
22:36 dalek MoarVM/inline: 2c6661f | jnthn++ | src/core/interp.c:
22:36 dalek MoarVM/inline: Make interp trace output more useful; include op.
22:36 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/2c6661fc97
22:36 dalek MoarVM/inline: 970700e | jnthn++ | src/spesh/ (3 files):
22:36 dalek MoarVM/inline: More robust (and correct) inline return addr deopt
22:36 dalek MoarVM/inline: review: https://github.com/MoarVM/MoarVM/commit/970700ef03
22:49 jnthn Next thing needed is multi-level uninline, it seems.
22:55 jnthn .tell brrt Looking at http://luajit.org/dynasm_examples.html could dynasm's macros be of any help in this?
23:41 jnthn sleep &

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary