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

Powered by Cro and the Raku® Programming Language.

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

Thank you!