Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-06

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:57 brrt joined #moarvm
05:59 brrt \o
06:05 leedo joined #moarvm
06:21 FROGGS joined #moarvm
06:37 brrt jnthn: can i perchance look at the not-so-jitted frame
06:38 nwc10 HEAD http://whisky-expert24.at/
06:38 nwc10 301 Moved Permanently
06:39 nwc10 Location: https://www.expert24.com/whisky/
06:39 * nwc10 needs to update some more regression tests. :-)
06:44 brrt jnthn: having .list generate an iterator memoizing into an array is really sensible. having it so close to .List which generates a List (which isn't size-extendable) may be a tripup
06:47 brrt as in, List generates something that is shape-immutable? (that's contrary to python, btw, where a list is a ... dynamic array with rather finicky semantics, and an array is a semi-dynamic array with even finickier semantics)
06:48 brrt btw, github making comments light gray is not the best possible UX
07:06 brrt hmm
07:07 brrt seems like i'll be failing to keep dasm_proto.h out of the list of all headers
07:09 brrt or, not
07:20 brrt ha ha
07:28 rurban_ joined #moarvm
07:54 zakharyas joined #moarvm
08:03 TEttinger joined #moarvm
09:28 brrt joined #moarvm
09:49 FROGGS src/jit/graph.c:1603:34: warning: initialization makes integer from pointer without a cast [enabled by default]
09:49 FROGGS { MVM_JIT_LITERAL, { NULL } } };
09:49 FROGGS ^
09:49 FROGGS src/jit/graph.c:1603:34: warning: (near initialization for ‘args[3].v.lit_i64’) [enabled by default]
10:57 brrt joined #moarvm
10:58 dalek MoarVM: cb95c6b | brrt++ | src/jit/graph.c:
10:58 dalek MoarVM: Fix warning in jit graph, FROGGS++
10:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cb95c6b29d
11:00 FROGGS \o/
11:01 brrt it's odd how assigning a literal 0 to a pointer value is ok and assinging NULL to an integer is not
11:01 jnthn Really
11:01 jnthn I'd have thought both would have counted as wrong level of indirection warning
11:01 FROGGS well, a pointer is a numeric value but a numeric value might not be a pointer
11:02 brrt in gcc, at least
11:02 brrt which is always happy to please :-)
11:56 brrt joined #moarvm
13:01 LLamaRider joined #moarvm
13:58 rurban_ joined #moarvm
14:04 brrt joined #moarvm
14:07 brrt hmm
14:08 brrt you all have not been able to actually *run* even-moar-jit for a while now :-(
14:19 * brrt is going to fix that
15:10 Ven joined #moarvm
15:55 FROGGS joined #moarvm
15:59 timotimo o, cool!
16:01 timotimo but what exactly does that even mean?
16:05 zakharyas joined #moarvm
16:45 zakharyas joined #moarvm
17:28 kjs_ joined #moarvm
17:40 dalek MoarVM/even-moar-jit: 53ce016 | brrt++ | / (5 files):
17:40 dalek MoarVM/even-moar-jit: Add support for 'destructive' templates
17:40 dalek MoarVM/even-moar-jit:
17:40 dalek MoarVM/even-moar-jit: Some opcodes prefer to write directly to vm memory (e.g. atpos and
17:40 dalek MoarVM/even-moar-jit: friends, exception result addresses). So we should support that and
17:40 dalek MoarVM/even-moar-jit: not insert a tree value for these nodes.
17:40 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/53ce016662
17:40 dalek MoarVM/even-moar-jit: 4e0326c | brrt++ | src/ (12 files):
17:40 dalek MoarVM/even-moar-jit: WIP - Tile implementation
17:40 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/4e0326c287
17:40 dalek MoarVM/even-moar-jit: 98d76bb | brrt++ | src/jit/ (8 files):
17:40 dalek MoarVM/even-moar-jit: Temporarily disable tiles to build a moar that runs
17:40 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/98d76bb76d
17:40 brrt joined #moarvm
17:43 brrt timotimo: that i was, or am, stuck in limbo there it wasn't possible to run moarvm, thereby not being able to check if my work makes any sense
18:04 timotimo ah
18:18 brrt hmmm
18:19 brrt i'm ambivalent with regards to labels
18:19 brrt internal labels to the expr tree, that is
18:20 brrt the best solution, i think, is to add a facility to allocate more labels at once
18:20 brrt that's easy enough to implement :-)
18:26 brrt but... but
18:31 brrt i'd need two passes
18:31 brrt one to count the ifs and whens
18:31 brrt and one to fill them in with labels
19:44 brrt joined #moarvm
19:52 dalek MoarVM/even-moar-jit: e58d670 | brrt++ | src/jit/ (2 files):
19:52 dalek MoarVM/even-moar-jit: Add call tile grammar
19:52 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e58d670d5f
19:52 dalek MoarVM/even-moar-jit: ff279dd | brrt++ | src/jit/ (6 files):
19:52 dalek MoarVM/even-moar-jit: Wrap dasm_State in MVMJitComiler structure
19:52 dalek MoarVM/even-moar-jit:
19:52 dalek MoarVM/even-moar-jit: This changes function signatures, but is not very exciting
19:52 dalek MoarVM/even-moar-jit: otherwise.
19:52 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ff279dd138
20:07 jnthn so boredom
20:07 jnthn brrt++
20:09 colomon_ joined #moarvm
20:13 brrt :-)
20:14 brrt (the goal is that the online register allocater and the assembler can be packed together)
20:15 brrt an offline register allocator, if any, can work in a preparation step
20:21 brrt jnthn: i would like some advice on something on which i'm a bit ambivalent
20:21 brrt it's about jit labels
20:22 brrt currently they're implemented as an array of void*; you add a pointer to something, and it checks if that pointer already exists
20:23 jnthn *nod*
20:23 jnthn Yeah, I think I encountered that a while ago when fixing an exception handler/inlining bug
20:23 jnthn (it was fine they were that way for fixing the issue)
20:23 brrt that's not wrong, per se, but i'm encountering the following
20:24 brrt it's not safe to  use pointers internal to the tree nodes, because the node buffer is realloced, and thus allowed to move
20:24 brrt e.g. i can potentially, within the same graph, allocate the same block, and assign the same label to different nodes
20:25 brrt this sucks, obviously
20:25 jnthn yes, fail
20:25 jnthn Does the node buffer ahve to be realloced?
20:25 brrt now during the analysis phase, the nodes are typically not added, therefore the block does not move, therefore i should be able to get away with it
20:25 jnthn As in, do you depend on contiguous allocation of the things?
20:25 brrt yeah, unfortunately
20:25 jnthn OK
20:26 jnthn Figured you must have a reason to not just spesh_alloc the things
20:26 brrt i have a chain of reasons :-)
20:26 brrt spesh_alloc cannot realloc
20:26 jnthn Right, by design :)
20:27 jnthn So we can be free to take pointers to nodes where we like in a spesh graph and feel safe :)
20:27 jnthn And so we can trivially free memory later
20:27 jnthn But I can see how that isn't the best way for everything.
20:28 brrt making the tree nodes buffer contiguous allows me to serialize it as integers and use indices, and that's really helpful during tree construction
20:29 brrt it's funny. i think we both made a different tradeoff, based on the fact that bytecode->spesh graph is an expansion, and spesh graph->expr tree is a lowering
20:30 brrt (the expansion adds and records but does not change the form of the code, i mean)
20:30 brrt well, that's not even entirely true, but still
20:31 brrt so, moving pointers and labels, bad
20:31 brrt two solutions
20:33 brrt a): we get away with this, because analyze doesn't ever move the tree. if we ever want to rewrite something and add an if/when, we move the labelling to a phase wherein nodes are guaranteed not to move
20:33 brrt a is clearly brittle
20:34 brrt b): we add a functionality to allocate a bunch of labels together, count the labels required, and acquire them based on the identity of the expr tree object itself. since this does not move, we have a stable base of identity
20:35 brrt b is not very difficult to implement, but it requires a good look at the labeling
20:36 brrt c): we use local labels only within an expression tree; an approach that does not scale (local labels do not need to be declared)
20:37 brrt b is clearly also sensitive to time-of-labelling
20:38 brrt that gives me an idea, though
20:38 brrt we use a, but we do it at compile time
20:38 jnthn Do the labels have to be identified by pointers to to something?
20:38 brrt i.e. add preorder entry
20:39 brrt well, no, that's mostly useful to distinguish different objects from one another
20:39 brrt and that's useful to distinguish e.g. instructions from basic blocks
20:40 brrt there are other ways to do that, i think
20:42 brrt hmm
20:42 brrt i like the 'do it at compile time' solution
20:43 brrt all it requires is a high-water-mark
20:43 brrt it's robust to optimizations, moves
20:44 brrt dasm supports it
20:44 brrt ok, i'm happy
20:44 kjs_ joined #moarvm
20:45 jnthn \o/
20:46 brrt :-) sometimes all it requires is a bit of puzzling
20:46 brrt now for the real challenge
20:47 brrt i want to... never mind
20:48 brrt the if-all case: jump over a block if any is false (or if-any: jump to block if any is true)
20:49 brrt but that's also doable
20:49 brrt by propagating the allocated label downward :-)
20:50 brrt ok, that's enough puzzles for tonight
20:51 brrt see you tomorrow!
20:53 jnthn brrt: Rest well!
20:53 jnthn brrt: See you tomorrow...I'll be doing Perl 6 stuffs tomorrow again also :)
20:53 brrt :-) awesome
20:54 jnthn "Korr för Pearl timmar i maj 2015" *snort*
20:54 * jnthn wonders where between him and the accountant the spelling went wonky :)
21:21 pyrimidine joined #moarvm
21:59 TEttinger joined #moarvm
22:15 kjs_ joined #moarvm

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