01:44
FROGGS joined
05:07
rurban_ joined
05:56
woosley joined
06:25
FROGGS joined
|
|||
FROGGS | o/ | 06:26 | |
07:06
zakharyas joined
07:13
ilbot3 joined
07:39
woolfy joined
08:31
donaldh joined
08:59
brrt joined
09:19
woolfy left
10:31
donaldh joined
11:10
d4l3k_ joined,
Util joined
11:11
tadzik joined,
sergot joined
11:12
masak joined
11:27
synopsebot joined
12:00
vendethiel joined
12:01
FROGGS joined
12:45
jnap joined
13:24
vendethiel joined
13:45
vendethiel joined
13:47
btyler joined
14:24
brrt joined
14:43
oetiker_ joined
14:48
oetiker__ joined
14:53
oetiker joined
14:55
oetiker joined
14:58
oetiker_ joined
14:59
oetiker joined
15:25
cognominal joined
|
|||
japhb | jnthn: Do you prefer I call the VM 'Moar' or 'MoarVM' in the architecture diagram slide of my why-perl6 talk? I see 'MoarVM' or 'moarvm' a lot here, but $*VM.name is 'moar'. | 15:26 | |
tadzik | is $*VM.name for JVM 'j'? :P | ||
japhb | tadzik: No, it's 'jvm'. But for the Parrot VM it's 'parrot'. | 15:27 | |
I currently have 'MoarVM', but I'm not certain what jnthn actually *wants* people to use, because the references I find are often historical. | 15:28 | ||
TimToady is biased towards claiming the "moar" meme pre-emptively before someone else does and confuses the market | 15:35 | ||
on top of which, saves two keystrokes :) | 15:36 | ||
tadzik | moar will be very hard to google | ||
TimToady | so you claim both words, and use "moarvm" at least once in any page :) | 15:37 | |
tadzik | :) | ||
TimToady | we also want people googling "moar fun" to end up on our page | 15:38 | |
jnthn uses "moar" informally, but sticks to MoarVM on the website, presentations, etc. | 15:52 | ||
TimToady | well, and we got the executable named "moar", which is something of a claim when you start installing it | 15:53 | |
(in a system directory) | |||
jnthn | aye :) | 15:55 | |
japhb | OK, so I'll stick with MoarVM for the architecture diagram, but I think I understand when to use moar. :-) | 16:01 | |
16:32
lizmat joined
17:54
brrt joined
|
|||
brrt | hi #moarvm | 17:57 | |
FROGGS | hi brrt | 17:58 | |
jnthn | hi brrt | ||
How's things? | 17:59 | ||
brrt | pff, tired, busy, lots of distractions | ||
:-) how are you? | |||
i had some really good ideas - i thought - and i've forgotten them | |||
jnthn | Still a bit tired from recent busy times... | ||
But gradually recovering and starting to write code again :) | |||
TimToady | brrt: writing things down helps a little, as you get older, but then you have to remember *that*... :) | 18:00 | |
and where you put your writings... | 18:01 | ||
brrt | i have a tendency to get good ideas in non-writeable situations | ||
TimToady | dictate to your phone? | ||
otoh, when I go back and look at my notes, they're usually crap :) | 18:02 | ||
brrt | i have a non-dictating phone, too :-) | ||
well, yeah, that too | |||
dalek | arVM/spesh_nameds: d9ad0cf | (Timo Paulssen)++ | docs/bytecode.markdown: Spec callsites storing named argument names. |
18:03 | |
jnthn | timotimo: I'm rescuing what I can from your branch on nameds in callsites, and will work on getting that stuff in place, so we can spesh 'em... | 18:04 | |
brrt | jnthn - i'm wondering, would it be better to JIT per MVMSpeshGraph or MVMSpeshBB? | 18:05 | |
jnthn | The first | ||
timotimo | that would be fantastic, thanks | ||
jnthn | I can't imagine how the second would work. | ||
TimToady | any phone is a dictating phone if you call up an answering machine you own :) | 18:07 | |
brrt | ... no, you're right :-) | ||
actually, compiling a graph by compiling basic blocks is probably reasonable | 18:08 | ||
TimToady | anyway, you planning to write the JIT JIT? :P | ||
jnthn | oh yeah, you may end up with a jit_bb | ||
Though will need a fixup table of back-jumps :) | |||
brrt | fixup table? | 18:09 | |
18:09
cognominal__ joined
|
|||
brrt | dasm can handle (dynamic) labels, by the way | 18:09 | |
jnthn | Ah...then it may do that for you :) | ||
brrt | hmm yes, i'll have to create 'some' structure, but as dynamic labels are really numbers it might well be sufficient to tag the basic blocks | 18:11 | |
and if i know how many basic blocks there are i can have dasm allocate a sufficient amount | |||
jnthn | g->num_bbs | 18:12 | |
brrt | but, i'm not sure if the jit graph ahs the exact same number of basic blocks as the spesh graph | ||
jnthn | Oh, point :) | 18:13 | |
Probably not :) | |||
jg->num_bbs :D | |||
brrt | why? because some things that are ops in the spesh graph will likely be functions in the jit graph, and function calls - iirc - form new basic block boundaries | ||
jnthn | No, function calls don't | ||
brrt | sure? | ||
jnthn | Well, they sure don't in spesh today :) | ||
brrt | hmm | 18:14 | |
no | |||
jnthn | You just proceed to the next instruction after the call. | ||
brrt | you;'re right | ||
however, for the purposes of register allocations, they are a boundary | |||
jnthn | True. | ||
JIT may want it called differently. | |||
brrt | you mean jit -> interpreted? | 18:15 | |
i'm wondering how often that happens, by the way | |||
if function foo is called N times, and foo calls bar, it's likely bar will be called N times as well? unless foo must decide to cal lbar, of course | |||
jnthn | No, I just mean JIT may have reason to treat calls as a BB end. | ||
brrt | oh i see | 18:16 | |
:-) | |||
jnthn | JIT -> interpreted can happen in two ways: code called conditionally that didn't get hot enough yet, and deopt. | ||
Oh, and returning from JITted to interpreted. | |||
Oh, and continuations I guess :) | |||
But aside from those cases, not that much :P | 18:17 | ||
brrt | i find continuations very difficult to think about in this context | ||
jnthn | From the JITs perspective you can largely treat them like function calls. | 18:18 | |
brrt | does moar have facilities to get (writable, executable) memory yet? | ||
ok i see | |||
jnthn | Not yet. | ||
brrt | doesn't matter, i'll place it in src/jit/ and if we ever find another use we'll move it | 18:20 | |
jnthn | wfm | ||
Well, src/platform/ is the other possible place. | |||
brrt | oh, that may be better | ||
jnthn | git why u no let me cherry-pick --no-commit 3 things... | ||
oh, it does | 18:22 | ||
brrt | what configuration variable holds the processor architecture? | 18:47 | |
(in Configure.pl) | |||
18:47
cognominal joined
|
|||
jnthn | brrt: I'm not sure there is one, looking at config.c | 18:49 | |
brrt: The probes so far have focused on features (like endianness) primarily I guess... | |||
brrt: build/probe.pm in unaligned_access is doing some architecture probing, it seems | 18:51 | ||
brrt | ok i'll check | ||
dalek | arVM/spesh_nameds: acf754b | jnthn++ | src/core/callsite.h: Prepare MVMCallsite for storing named arg names. |
19:27 | |
arVM/spesh_nameds: 1958884 | jnthn++ | src/ (2 files): Start placing arg names into callsite objects. This writes them into the bytecode file and then later reads them back in. Not using them for anything yet; we'll be able to use them as part of spesh, and can gradually with time migrate to using them everywhere and then exclude them from actually being passed in call sequences. |
|||
jnthn | Patches based on timotimo++ work, but in the case of mast/compiler.c heavily re-worked to get re-use righter. | 19:28 | |
dalek | arVM/spesh_nameds: 14b88fc | jnthn++ | src/core/bytecodedump.c: Update bytecode dumper to dump arg names. |
19:42 | |
jnthn | walk; bbiab to work on interning callsites with nameds... | 19:52 | |
20:17
lizmat joined
|
|||
brrt | hmm jnthn, anyone else: have an idea of how to put an 'optional' part like jit into the Makefile? | 20:18 | |
or rather | 20:19 | ||
jnthn | Just put it in there any then have the dependency on it be optional, mnaybe? | ||
brrt | yes, hmm | 20:20 | |
i don't know if that will work out | |||
jnthn | OK | ||
Well, otherwise it's just an @foo@ where foo is a multi-line thingy :) | |||
brrt | i tried that, i'm stuck in the 'solve this elegantly' trap :-) | ||
also, i need to compile some stubs for compiling on a platform without jit support | 20:21 | ||
jnthn | aye | 20:22 | |
In which case can you not have a @jitfiles@ that specifies the files to compile? | 20:23 | ||
brrt | yes | ||
thats what the platform logic seems to be doing | |||
so thats what i'll do too | |||
how should we determine where lua comes from? | 20:29 | ||
parameter passing? | 20:30 | ||
jnthn | Parameter to Configure.pl you mean? Can do...and if not specified just try a straight "lua" invocation | 20:33 | |
brrt | yes, thats what i mean :-) | ||
jnthn | wfm :) | 20:34 | |
20:47
japhb_ joined
|
|||
brrt | hmm, why is the generated makefile automatically removing the generated .c file (from the .dasc file) | 20:51 | |
jnthn | Something stray in cleanups? | 20:56 | |
brrt | not that it matters much | ||
but still | |||
jnthn | Well, it does if we're going to check it in, no? | 20:57 | |
brrt | yes :-) | ||
i'm watching it build right now | 20:58 | ||
OT - what does anyone here think of this new 'Swift' language? | |||
jnthn | brrt: Was some discussion on #perl6 about it earlier today :) | 21:00 | |
I read through the manual this morning quickly. | 21:01 | ||
Conclusion: nice language, nothing earth-shattering, but overall quite well balanced. | |||
brrt | i shall look at said discussion | ||
ugh, i'm so darned close | 21:10 | ||
oh, wait, i see | 21:11 | ||
src/jit/jit.o is linked in libmoar.so to which moar is linked, but functions in jit.o aren't actually visible to the moar executable until made 'public' | 21:12 | ||
how do i make a function public? | |||
jnthn | MVM_PUBLIC? | 21:13 | |
brrt | yes :-) | 21:14 | |
thanks | |||
hmm thats not good enough it seems | 21:18 | ||
jnthn | Oh? | 21:19 | |
You put it in the header? | |||
brrt | yes | 21:20 | |
basically, i'm trying 'hello world' here :-) | |||
i have this function MVM_can_jit(MVMSpeshGraph *graph), and it should return 0, and in main.c i call it with a printf() | |||
but it can't seem to link to it in libmoar.so | |||
jnthn | You added yoru header file in moar.h too? | 21:21 | |
brrt | yes | 21:28 | |
it does appear in libmoar.so | 21:35 | ||
21:35
lizmat joined
|
|||
jnthn | It's not some weirdness with it finding an intalled version of the library? | 21:37 | |
(yes if "make install" fixes it) | 21:38 | ||
brrt | yes, its weirdness with finding an installed version of the library | 21:39 | |
darnit | |||
:-) | |||
just as you were saying it | |||
21:50
woolfy joined
|
|||
dalek | arVM/spesh_nameds: d156625 | jnthn++ | src/core/callsite.c: Start interning named arg callsites. |
21:53 | |
arVM/spesh_nameds: 56a9b99 | jnthn++ | src/spesh/args.c: Make spesh survive named arg call sites. Doesn't do the named to positional bit yet, but this at least gets it to not do an optimization that loses named args if they're slurped. |
|||
arVM/moar-jit: b0a35b7 | (Bart Wiegmans)++ | / (9 files): Added rules to pre-process and compile DynASM files. |
21:54 | ||
jnthn | Seems that's already a small win... | ||
21:56
LLamaRider joined
|
|||
jnthn | brrt++ # yay, progress | 21:57 | |
brrt | small wins :-) | ||
ok, whats next | 22:01 | ||
oh yes | 22:02 | ||
i recall | |||
do you have any pointers on how to build a MAST tree and the compile it? | |||
22:05
donaldh joined
|
|||
jnthn | use MASTNodes; # gets you the nodes | 22:06 | |
my $mc := nqp::getcomp('MAST'); # gets you the compiler | |||
And you can do $mc.assemble_and_load($mast_tree) to get it compiled and loaded. | 22:07 | ||
brrt | :-) ok, awesome | 22:08 | |
jnthn | A MAST tree is always a MAST::CompUnit at the top, then at least one MAST::Frame; you .add_frame on the CompUnit. | ||
And frames get instructions or instruction lists pushed onto them. | |||
Note that you can --target=mast | |||
To get an idea | 22:09 | ||
brrt | --target=mast does.. . create files with MAST nodes? | 22:12 | |
oh i see | 22:14 | ||
jnthn | no, dumps | ||
brrt | i see.... takes a bit of time to get used to inspecting | 22:23 | |
it seems like a time for sleeping for me | 22:30 | ||
see you tomorrow! | 22:31 | ||
22:31
brrt left
|
|||
jnthn | Night! o/ | 22:32 | |
23:06
woolfy left
23:23
woolfy joined
23:54
woolfy joined
23:59
lizmat joined
|