Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-23

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

All times shown according to UTC.

Time Nick Message
01:46 colomon joined #moarvm
01:49 vendethiel joined #moarvm
11:25 brrt joined #moarvm
11:25 brrt good *
11:26 brrt i have something approaching good news
11:26 brrt we're going to have a cool register allocation algorithm
11:26 brrt to be sure, the same register allocation algorithm as luajit has
11:27 brrt (linear scan register allocation. http://www.seas.gwu.edu/~hchoi/teaching/cs160d/linearscan.pdf
11:28 brrt works Well Enough and is simple to implement, moreover can work inline
11:28 brrt all this comes for free with just one minor abstraction
11:29 brrt instead of the node number for first-and-last use, we assign compilation order numbers to DAG nodes
11:29 brrt the first and last compilation order number of the user forms a live range
11:30 brrt this also solves the problem of 'what values do we need to spill prior to a conditional or a function call' quite elegantly
11:30 brrt because the CALL or IF node is the last node to be numbered in this way
11:32 brrt and the answer to 'which values should be spilled' is simply 'all those values with a live range extending beyond the CALL node'
11:32 brrt clearly, that should happen in preorder order
11:34 vendethiel brrt++ :-)
11:35 brrt there is one minor other problem.... i'm not 100% sure how  up-propagate register requirements over conditionals
11:38 FROGGS_ joined #moarvm
12:07 masak well, how does luajit do it?
12:14 brrt actually, i don't know that for sure
12:14 brrt what i do know is that luajit is not a good and easy source of inspiration
12:14 brrt luajit is quite convoluted code
12:39 JimmyZ you can't understand luajit well enough without debugging it ;)
12:40 brrt i can imagine that
12:43 JimmyZ well, the spesh stage of luajit is easier than jit  stage
13:21 dalek MoarVM/even-moar-jit: 2bcae41 | brrt++ | src/jit/ (8 files):
13:21 dalek MoarVM/even-moar-jit: WIP - Register allocation
13:21 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/2bcae41350
13:21 brrt left #moarvm
13:47 Ven joined #moarvm
13:54 zakharyas joined #moarvm
14:15 FROGGS o/
14:46 timotimo i might be able to turn at least half of graph.c into tree expression form today
14:59 colomon joined #moarvm
16:19 colomon joined #moarvm
17:38 zakharyas joined #moarvm
18:28 Ven joined #moarvm
18:31 TEttinger joined #moarvm
18:50 Ven joined #moarvm
19:05 Ven joined #moarvm
19:10 Ven_ joined #moarvm
19:14 brrt joined #moarvm
19:16 brrt timotimo++
19:27 brrt joined #moarvm
19:50 ggoebel joined #moarvm
19:58 timotimo brrt basically came over to ++ me? :S
19:58 brrt yes
19:59 brrt because you said you could maybe convert the graph.c to exprlist format
19:59 brrt which tells me you've been busy with it
19:59 brrt which I greatly appreciate :-)
20:00 timotimo ah
20:00 timotimo oh, i didn't see you came back right after
20:01 brrt well, here i am
20:02 timotimo right
20:02 timotimo my code structure is a bit weird, though
20:03 brrt as long as it works
20:03 Ven joined #moarvm
20:03 brrt even if it'd worked only once
20:04 brrt on a blue moon
20:04 timotimo yeah
20:06 zakharyas joined #moarvm
20:09 Ven joined #moarvm
20:16 timotimo for making the resulting trees, i refer to a register with $operand-index-that-supplies-the-register?
20:16 brrt joined #moarvm
20:16 timotimo seems right
20:17 brrt my internet connection is extremely flaky today
20:17 timotimo :(
20:17 brrt i probably missed something you just said :-)
20:18 brrt it's an effect of sitting in the train speeding home
20:18 timotimo 221518  timotimo │ for making the resulting trees, i refer to a register with
20:18 timotimo │ $operand-index-that-supplies-the-register?
20:18 brrt therefore temporary
20:18 brrt yes, pretty much
20:19 brrt the idea is that those operands are marked as read-register usually
20:19 brrt typically
20:19 timotimo how do string indices look with regard to that?
20:19 brrt and in that case, the tree builder generates the load-register code for that operand
20:19 brrt well, a string index is a 32 bit constant, right?
20:20 timotimo what does our jit do with MVM_JIT_STR_IDX?
20:20 brrt the tree builder also generates constant-value nodes for string index values
20:20 timotimo mhm
20:20 brrt lemmesee
20:20 timotimo right
20:21 brrt see src/jit/expr.c:L90
20:22 timotimo but how does it look in the expr template code i ought to emit?
20:22 brrt the MVM_JIT_STR_IDX arg type loads the string literal pointer
20:22 brrt so we actually use a macro for that in core.expr
20:22 timotimo ah
20:22 timotimo oh
20:22 timotimo ^cu_str
20:22 timotimo ^cu_string
20:22 brrt it'd look like (load (^cu_string $1) ptr_sz)
20:22 timotimo i missed that when i looked
20:23 brrt because the (^cu_string) gives you an address, not a value
20:23 brrt basically exactly like the const_s template
20:23 timotimo right
20:23 timotimo that makes sense
20:24 brrt :-)
20:40 timotimo i was skipping almost all ops because i was expecting MVMint64 or MVMint32, but not MVMint16
20:43 timotimo ugh
20:44 timotimo since i can't keep this loop a postconditional, but i want to put "$line = @lines.shift" into the condition, i'm just going to unshift a copy of the last line i tried to match into the list before going on m)
20:49 timotimo oh
20:49 timotimo the carg for the end wants to know int vs ptr
20:49 timotimo do i have an obligation to look at the instructions themselves to see what arguments are obj, str, num, int?
20:50 timotimo i mean, num is signified with an _F always
20:50 timotimo i hope brrt didn't fall off the 'net again :S
20:51 brrt still here
20:51 timotimo great!
20:51 brrt no, you can infer it from the arg type
20:51 brrt num is indeed always signified by _F
20:52 timotimo oh, ptr is only for REG_ADDR?
20:52 brrt no
20:52 brrt ptr is any ponter type, including strings
20:52 timotimo so obj and str registers?
20:52 brrt aye
20:53 timotimo how do i find out what it is? :)
20:53 brrt REG_ADDR can only be compiled *iff* that argument is a write-to-register value, because only then does the tree builder generate the address rather than the load of the value
20:54 brrt you don't really have to worry about the difference tbh
20:54 brrt if you would really want to i guess you could parse oplist
20:54 timotimo OK, will i just always emit "int"?
20:54 timotimo i don't have to parse oplint any more, we have a perl6 module that's generated from oplist
20:54 brrt that works for now. on x64, ints are always as large as ptrs
20:54 brrt oh, right
20:55 brrt well, that would be a good way to get the required information, methinks
20:55 timotimo mhm
20:55 timotimo oh, look at that
20:55 timotimo i already "use" that module anyway :)
20:57 brrt yeah, i think that may help
20:57 brrt it's best practice to distinguish them. on ARM or other 32 bit archs, pointers are not 64 bits wide
20:57 timotimo thing is, i do multiple ops at the same time; let's just hope all ops that have the same piece of code have the same obj/str vs int vs num "form" :)
20:58 brrt hmm yes
20:58 timotimo later on i want to have a distinguisher anyway to handle things like the ? : operator used in the array
21:00 brrt right
21:00 brrt keep it simple for now
21:01 brrt it's not like i'm done with the register allocator anyway :-)
21:02 timotimo :)
21:02 brrt although it's not that far off, either
21:02 brrt i'm wondering if using a heap actually makes sense
21:02 brrt it's elegant, but we have so few registers at any one time
21:04 timotimo ugh
21:04 timotimo my parser routine for the opcode to cfunc function seems broken
21:09 brrt :-(
21:09 brrt c is maybe a bit hard to parse
21:09 brrt isn't there perhaps a cpan module for that
21:12 timotimo hah
21:12 timotimo i was going with a very naive approach
21:12 timotimo it seemed to work well a few days ago
21:12 timotimo oh, haha
21:14 brrt naive is ok
21:14 brrt but i wonder how much memory you're currently using :-P
21:15 timotimo haha
21:17 timotimo Grammar::Tracer needs an "ignored_by_tracer" trait :S
21:17 timotimo it's basically only lines of matched whitespace
21:19 brrt1 joined #moarvm
21:19 brrt1 very connect
21:19 brrt1 many reliable
21:20 brrt1 grammar::tracer is a perl6 module?
21:20 timotimo yes
21:21 timotimo now i've removed sigspace for a little bit of my grammar and the trace output became much more useful
21:21 timotimo but only very slightly so :(
21:21 timotimo i'll probably turn the whole-file grammar into a line-by-line thing instead
21:22 brrt1 hmmm
21:22 brrt1 maybe that's a good idea
21:22 brrt1 good old fashioned perl5-style-parsing with regexes ^^
21:25 timotimo ack!
21:25 timotimo someone must have changed the code to remove the '&' before all the function names
21:25 timotimo that's what broke my naive grammar %)
21:26 brrt1 wait, what, why is there no ampersand?
21:27 timotimo no need
21:27 brrt1 really?
21:27 brrt1 and that's not a compiler warning on clang?
21:27 timotimo don't think so?
21:27 timotimo i dunno
21:28 timotimo [...]trify("MVM_coerce_smart_stringify"), :MVM_OP_sp_boolify_iter("MVM_iter_istrue"), :MVM_OP_splice("MVM_repr_pos_splice"), :MVM_OP_split("MVM_string_split"), :MVM_OP_sqrt_n("sqrt"), :MVM_OP_sub_I("MVM_bigint_sub"), :MVM_OP_substr_s("MVM_string_substring"), :MVM_OP_takeclosure("MVM_frame_takeclosure"), :MVM_OP_tan_n("tan"), :MVM_OP_tc("MVM_string_tc"), :MVM_OP_throwcatdyn("MVM_exception_throwcat"),
21:28 timotimo :MVM_OP_throwcatlex("MVM_exception_throwcat"), :MVM_OP_throwcatlexotic("MVM_exception_throwcat"), :MVM_OP_throwdyn("MVM_exception_throwobj"), :MVM_OP_throwlex("MVM_exception_throwobj"), :MVM_OP_throwlexotic("MVM_exception_throwobj"), :MVM_OP_time_n("MVM_proc_time_n"), :MVM_OP_uc("MVM_string_uc"), :MVM_OP_unbox_i("MVM_repr_get_int"), :MVM_OP_unbox_n("MVM_repr_get_num"), :MVM_OP_unbox_s("MVM_repr_get_str"),
21:28 timotimo :MVM_OP_unshift_i("MVM_repr_unshift_i"), :MVM_OP_unshift_n("MVM_repr_unshift_n"), :MVM_OP_unshift_o("MVM_repr_unshift_o"), :MVM_OP_unshift_s("MVM_repr_unshift_s"), :MVM_OP_usecapture("MVM_args_use_capture"), :MVM_OP_write_fhs("MVM_io_write_string"), :MVM_OP_wval("MVM_sc_get_sc_object"), :MVM_OP_wval_wide("MVM_sc_get_sc_object")}<>
21:28 timotimo that looks better
21:28 brrt1 oh, nice!
21:29 timotimo (template: MVM_OP_prof_allocated
21:29 timotimo (call (^func MVM_profile_log_allocated)
21:29 timotimo (arglist 2
21:29 timotimo (carg (tc) ptr)
21:29 timotimo (carg $0 int)
21:29 timotimo ) ) )
21:29 timotimo (template: MVM_OP_radix_I
21:29 timotimo (call (^func MVM_bigint_radix)
21:29 timotimo (arglist 6
21:29 timotimo (carg (tc) ptr)
21:29 timotimo (carg $1 int)
21:29 timotimo (carg $2 int)
21:30 timotimo (carg $3 int)
21:30 timotimo (carg $4 int)
21:30 timotimo (carg $5 int)
21:30 timotimo ) ) )
21:31 timotimo sometimes we don't seem to have an entry in the op_to_func, it seems
21:33 brrt1 hmm.. it may be that the & is not *really* necessary, but i do prefer it
21:33 brrt1 maybe it's defined inline?
21:33 timotimo right
21:33 timotimo hm?
21:33 timotimo Use of uninitialized value %opcode_to_cfunc of type Any in string context  in block  at tools/parse_jitgraph.p6:177
21:33 timotimo this seems kinda wrong
21:34 brrt1 huh, yeah
21:35 timotimo ah, i know
21:35 timotimo i had an array as the key and value of a Pair object
21:36 timotimo only .list'd the value, not the key
21:36 timotimo so i was looking for ops called, for example, "MVM_OP_foo_bar MVM_OP_bar_baz"
21:37 brrt1 right
21:37 * brrt1 will disconnect in a few minutes
21:38 brrt1 left #moarvm
21:44 timotimo https://gist.github.com/timo/afb0413f1aead980a275 - you may like what you see here; sadly, gist put the interesting file last, the error output file first
21:44 timotimo hm, i may have to resend this when brrt comes back
21:49 timotimo ah, "uint" trips it up currently
21:49 timotimo i don't think it makes any difference, though
21:55 timotimo huh
21:55 timotimo sometimes the MVMJitCallArgs array starts like         MVMJitCallArg args[] = { { MVM_JIT_INTERP_VAR, MVM_JIT_INTERP_TC },
21:55 timotimo MVMJitCallArg args[] = { { MVM_JIT_INTERP_VAR, { MVM_JIT_INTERP_TC } },
21:55 timotimo ^- this is the format i expect
21:59 * timotimo uploads a new version
22:00 timotimo https://gist.github.com/timo/afb0413f1aead980a275 - same url, but i thought i'd repost
22:11 timotimo it doesn't handle adding a "void" at the end yet if the return value is void
22:20 timotimo i surely need to care about num return types, too
22:33 timotimo updated yet again
22:33 timotimo where is brrt to cheer? :S
22:38 timotimo i'm right in assuming that the rest of the jit compiler handles what the return value's destination register is supposed to be, yeah?
22:40 dalek MoarVM: 5011c98 | timotimo++ | src/jit/graph.c:
22:40 dalek MoarVM: make jit/graph.c a tiny bit more regular for the parser
22:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5011c98a23
22:40 dalek MoarVM: 7dea708 | timotimo++ | tools/parse_jitgraph.p6:
22:40 dalek MoarVM: at long last, turn jit/grap.c into an expr tree (for the most part)
22:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7dea708fee
22:41 timotimo in the end it was quite a bit easier than i had feared
22:45 dalek MoarVM: 8d5ec6a | timotimo++ | tools/parse_jitgraph.p6:
22:45 dalek MoarVM: record more skips from different bail modes
22:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8d5ec6a409
23:06 timotimo when there's a lit_i16, i'd use (const $1234 16), right? because int_sz is too big?
23:07 timotimo on the other hand, if it's a constant, doesn't make a difference if int_sz is bigger than what the const needs to get stored
23:08 timotimo especially when we pass it as an arg to a c function
23:08 timotimo hm. or maybe i have to use (copy $123)? probably.
23:10 timotimo hm, but it is important for reading from the opcode, which is done before templates are interesting at all, right?
23:10 timotimo so probably nothing to worry about when i'm already matching a template onto the tiled tree
23:14 timotimo i'm apparently confused about what things are
23:15 timotimo yeah, it'll be just like const_i16, which does a copy on the $123, so that's what i'll have to do, too
23:48 dalek MoarVM: 27dbca3 | timotimo++ | tools/parse_jitgraph.p6:
23:48 dalek MoarVM: tally succ/fail, factor out report_unhandled, ...
23:48 dalek MoarVM:
23:48 dalek MoarVM: ... handle literals, be more careful about INTERP_VAR
23:48 dalek MoarVM: (used to treat every INTERP_VAR like TC before), don't be
23:48 dalek MoarVM: flabbergasted when the jgb_append_call_c is spread across
23:48 dalek MoarVM: two lines.
23:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/27dbca31f6
23:52 dalek MoarVM: ed6dda3 | timotimo++ | tools/parse_jitgraph.p6:
23:52 dalek MoarVM: handle the CU interp var, too.
23:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ed6dda32b4
23:54 timotimo i think i need a little macro for "args", which would be quite a bit like ^parg, but without the (idx ... ,a reg_sz) i imagine
23:54 timotimo oh, and also without the "load", because it wants to pass the pointer to the args object
23:56 dalek MoarVM/even-moar-jit: 598cd62 | timo++ | src/jit/core.expr:
23:56 dalek MoarVM/even-moar-jit: add ^args macro
23:56 dalek MoarVM/even-moar-jit:
23:56 dalek MoarVM/even-moar-jit: some C functions we may want to call will want a pointer
23:56 dalek MoarVM/even-moar-jit: to the args object of the current frame.
23:56 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/598cd62641
23:57 timotimo oh, i think i want to get rid of the .params, too
23:57 timotimo and call it ^params instead of ^args

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