00:16 cognominal joined 01:08 btyler joined 01:26 FROGGS_ joined 03:38 btyler joined 05:31 woosley joined 05:35 odc joined 07:05 zakharyas joined
nwc10 jnthn: still not broken. 07:41
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
07:46 brrt joined
nwc10 masak: < jnthn> Well, yeah, but collateral damage is also possible. 07:46
:-) 07:47
masak ah :)
brrt morning folks 07:55
FROGGS morning 07:56
jnthn morning o/ 08:09
FROGGS morning jnthn 08:10
08:12 lue joined 08:34 FROGGS[mobile] joined 08:50 FROGGS[mobile]2 joined
dalek arVM/moar-jit: 5a27f9b | (Bart Wiegmans)++ | src/ (9 files):
Preliminary jit graph compilation.

This doesn't actually compile anything useful, however it will construct a proper function prologue and epilogue. I've also changed the platform 'mmap' functions so that I can use them - they weren't used before.		 08:55
brrt morning jnthn 08:59
09:06 Util joined
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:06
1 - the 'jit' frame - i.e. the stack space that holds (in my case) the threadcontext and the frame 09:07
2 - the 'work' registers - i.e the usual moarvm work space
3 - lexicals
4 - constants / literals 09:08
i'm forgetting quite a few
masak don't need an exhaustive list to get something simple/working off the ground... 09:17
brrt i suppose not 09:20
09:24 synopsebot joined
jnthn 5 - returned from C functions you mgiht call that implement VM-internal things. 09:42
Also there's incoming args. 09:43
brrt oh, thats a good one
on x86_64, a return is always in rax 09:44
brrt wonders what happens when you return a struct
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
er, ABI docs
brrt hmmm.. i recall reading that
09:47 vendethiel joined
brrt i'm going to see what gcc / clang does 09:47
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:50
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
even though you are calling with a(n otherwise) sane sequence of arguments)
brrt i know, i tried printf and it burned me in just that way
:-)
also because i had the printf function in the rax register 09:52
(long, dynasm specific story, not very interesting)
and the rax register is where the number of varargs are held
nwc10 I didn't know this. I found it out the hard way
(why is this C code crashing, once I try to write a test for it)
brrt en.wikipedia.org/wiki/X86_calling_conventions is a pretty reasonable reference 09:54
&lunch 10:17
11:03 FROGGS joined 11:08 brrt joined
brrt ok, mike pall says dynamic registers on x64 are broken 11:08
that is... a pain
but its ok i guess
timotimo "dynamic registers"? 11:14
is that "x86_64 sucks and the feature 'dynamic registers' it offers is pretty much useless"? 11:15
brrt ehm... its more subtle than that 11:18
there is - afaik - a register renaming feature in (some) x86_64, but thats not what i mean :-) and its not 'public' either, i think
i mean the dynasm feature that has you refer to a register by number 11:19
and that doesn't work on any other platform than x86, including x86_64, because - i'm paraphrasing - register encoding is hard 11:20
i.e. encoding where the results of a register go to
that, though, can be interpreted as 'x86 / x64 is suboptimal', but that shouldn't surprise anyone :-) 11:21
timotimo oh, crap :( 11:22
brrt yes, well the alternative is writing a huge switch clause 11:24
timotimo :| 11:33
11:35 FROGGS joined 12:11 colomon joined 12:33 jnap joined
brrt afk 12:35
12:41 harrow joined 12:47 brrt joined
brrt back 12:47
jnthn to the future 12:49
brrt :-D 12:51
brrt is off writing his huge switch tables
jnthn Bet you don't beat interp.c's one :P 12:52
brrt maybe not 12:54
but i'll get close :-P
or, to put it in other words 12:56
have any clever way of creating a 16x16 jump table as a #define statement
jnthn Does it have to be a jump table? Can't do it with a static array? 12:57
brrt i'll explain the challenge in full, maybe you see something clever 12:58
basically, i need to compile an add instruction, right? 12:59
(this is going to sound more convoluted than it really is)
jnthn
.oO( addition...so complex :D )
brrt ok, i need at least one of the add instructions to be a register
which register should that be? well, don't care at this point, any register 13:00
jnthn You mean operands?
brrt yes, operands :-)
hmmm 13:02
ok, still haven't explained it huh
:-)
basically, i want something like emit_op(op, reg1, reg2)
jnthn Are we talking about MoarVM registers or CPU ones at this point? 13:03
brrt cpu registers
:-)
jnthn ok.
brrt ok, for that to work, i need to have dasm say something like | op reg1, reg2
but as i see it now, thats not actually possible with a c-preprocessor macro 13:04
because dynasm runs before cpp does
jnthn The issue being you have to know *which* reg?
13:05 colomon joined
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
that is possible, but that is pretty slow 13:07
jnthn Yeah, that sounds wrong
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
I really don't think we should start cheating on that until we have it working that way.
brrt true
hmmm
ok, i guess i could get away with static register allocations for now
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:10
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
jnthn *speculative opts
And inline, and so forth.
Yes, I think so :)
brrt but its' not where i want to go :-)
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.
brrt no, of course not
jnthn But it will means we get a viable JIT sooner. :) 13:13
*mean
brrt it means i can go ahead now
:-)
jnthn aye 13:14
13:14 vendethiel joined
nwc10 erk. this isn't right. I'm 20% last month: www.ohloh.net/p/moarvm/contributors/summary 13:41
nebuchadnezzar hello 13:48
Is there a way to make the libdir target configurable? 13:49
something like --libdir=<path to lib>
I'll need to patch build/setup.pm to support MultiArch otherwise ;-)
13:50 donaldh joined, donaldh left
FROGGS MoarVM itself only cares about --prefix 13:51
nebuchadnezzar yes, the lib is put under @prefix@/lib, for MultiArch I need to change the /lib to /lib/<triplet> 13:52
FROGGS then we need to adjust setup.pm, yes 13:53
nebuchadnezzar I'll fill a request on github for this, work on a Debian specific patch and submit it if it works 13:54
I support Configure.pl must be changed to handle the new --libdir option? 13:55
jnthn Sounds reasonable. 13:57
FROGGS is that about /lib only? I mean, /include can be left untouched?
nebuchadnezzar FROGGS: yes, /include files are shared accross architectures 13:59
FROGGS k
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
nebuchadnezzar I had a message from lintian about the use of RPATH: lintian.debian.org/tags/binary-or-s...rpath.html 14:05
I made a little Debian patch to remove it paste.debian.net/104110/ 14:06
brrt off again 14:07
14:07 brrt left 15:14 cognominal joined 16:40 FROGGS joined
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
and then will hack inline some more
timotimo also, it'd be good to know where the first spot is where we hit the missing deopt things in the inliner
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:07
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:08
(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
timotimo: Not sure the latest blocker is deopt any more...
Though bits of it are still missing
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"
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:10
timotimo jnthn: do we already get through a setting compilation? 18:25
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
jnthn Right
You need to turn-on patch here to actually make it erupt. 18:27
18:28 brrt joined
nwc10 spectest is consistent with MoarVM master under ASAN. 18:30
so "we have normality, I repeat, we have normality" and "anything you can't deal with is therefore your own problem"
timotimo jnthn: argh 18:48
jnthn timotimo: uh, that's not actually true 18:49
timotimo: We surive startup fine. We don't survive parsing much because it starts inlining, say, CAPS into CAPHASH
japhb_ If inlining is good, inlining more must be better, right? 18:52
timotimo oh, hehe.
though i'm not sure why it's bad to inline CAPS into CAPHASH 18:53
jnthn It's *fine* to do so 18:54
timotimo unless you're doing it wrong? :)
jnthn It's just that at some point CAPHASH does and deopts.
Though that is OK too for now...
timotimo ah, that makes sense
jnthn I think the problem may be more that I didn't start GC-marking locals and lexicals that got inlined.
timotimo oh!
that's cute :)
ticking time bomb etc etc 18:55
jnthn And the last issue I got was a SEGV with a bad pointer
So that's my next thing to tend to :)
timotimo the pointer itself was bad?
jnthn Looked like
timotimo maybe setting the "set old nursery spaces dont-read-dont-write" thing again would help?
jnthn Well, looked like a pointer that was once legit, but now is pointing at junk
Well, let me put in the fix for the thing I *know* is broken before doing real debugging :)
timotimo ah, i thought maybe it was a pointer that wasn't even aligned or something 19:01
19:19 FROGGS[mobile] joined
[Coke] moar is now the only clean spectesting rakudo. 19:27
jnthn Time to write moar tests 19:29
masak :P
19:30 cognominal joined
[Coke] fix the ones that are still borking! ;) 19:35
(for other rakudos‚
19:56 FROGGS joined 20:38 raiph joined
dalek arVM/inline: b445462 | jnthn++ | src/spesh/ (5 files):
Build up inline-aware local/lexical type maps.
 20:42
brrt i have a bug on my screen :-D 20:43
a literal bug
and its off again 20:44
dalek arVM/moar-jit: d94b314 | (Bart Wiegmans)++ | src/ (6 files):
Naive per-instruction compilation of a few opcodes.
 20:45
arVM/moar-jit: 476ccc2 | (Bart Wiegmans)++ | src/jit/x86_64. (2 files):
Added argument setup for c calls.

This works only for the first three arguments- fourth argument would overwrite our work pointer - and only for integers. Still, should be enough to call a few MVM internal functions.
FROGGS O.o
brrt also known as - the commits that deleted MVMJitGraph 20:46
tadzik fun :) 20:47
brrt well,..... i'm not so terribly happy with it all 20:48
i'll be blogging about it
raiph brrt++ # commits 20:49
++brrt # blog 20:50
brrt ahead of time eh? :-)
jnthn brrt++ # progress 20:52
Turns out we didn't even do a GC run at the point things explode, so it's probably an uninline bug. 20:53
nwc10 jnthn: b445462cfce2b67e4ac98f66bcfec62abc7cf925 not broken 21:06
21:19 donaldh joined 21:45 jnap joined
brrt jnthn -> brrt-to-the-future.blogspot.nl/2014/06/news.html :-) 22:02
your advice greatly appreciated
brrt &sleep 22:03
22:04 brrt left
FROGGS gnight brrt 22:04
timotimo brrt: doesn't sound very happy :( 22:26
dalek arVM/inline: 2c6661f | jnthn++ | src/core/interp.c:
Make interp trace output more useful; include op.
 22:36
arVM/inline: 970700e | jnthn++ | src/spesh/ (3 files):
More robust (and correct) inline return addr deopt
jnthn Next thing needed is multi-level uninline, it seems. 22:49
.tell brrt Looking at luajit.org/dynasm_examples.html could dynasm's macros be of any help in this? 22:55
sleep & 23:41

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!