timotimo yeah, that's right 00:01
dalek arVM/even-moar-jit: 36e4147 | timo++ | src/jit/core.expr:
it's ^params we need, not ^args
timotimo i wonder if i should even make a macro for FRAME, as it's so simple 00:05
oh
it'll literally just be (frame)
dalek arVM: 5279415 | timotimo++ | tools/parse_jitgraph.p6:
handle INTERP_FRAME and INTERP_PARAMS
 00:07
timotimo and CALLER has an "aword" in its implementation in emit.dasc ... not sure if that has to be reflected in the macro for it 00:08
huh. also, FRAME uses mov, PARAMS has a -> and uses lea, but CALLER has a -> and uses mov 00:09
oh, that's because params is actually inline 00:11
in that case, i'm not 100% sure any more my implementation of ^params is correct; was the (load ...) in ^pargs equivalent to a lea instruction? 00:12
brrt, i don't yet know how to spell what MVM_JIT_REG_ADDR wants to become, so this is where i'll stop for today and go to bed 00:15
felt good to get some actual progress done for a change 00:16
01:22 vendethiel joined 03:18 lizmat joined 05:27 ggoebel joined 06:48 zakharyas joined 07:02 Ven joined 07:41 brrt joined
brrt good moarning 07:42
i have some... profoundly mediocre news
i just realised that the 'spill to stack' method will not work across invokish() ops
:-( 07:44
JimmyZ doesn't know it is good or bad news :)
brrt it's bad, bad, bad news 07:52
i'm not even sure how to fix it news
it sucks
well, damnit, i do know how to fix it 07:53
it mean creating a JIT temp space and using that rather than the stack
hmm
that's still not pretty but a lot better than no way to fix it 07:54
bbiab, updates 08:03
actually, now that i think about it, my very own temporary space also has some advantages
08:17 brrt joined
brrt timotimo++ (just backlogging) 08:17
also, aword is dynasm speak for pointer-size, i.e. ptr_sz 08:18
reg_addr, in probably 100% of cases, is simply the operand itself 08:24
because you use reg_addr to pass the address for something to write
which means that in pretty much all cases i've seen, it's the address of the written operand 08:25
which is provided to you as the $0 operand by the tree builder
provided the first operand is actually a write-operand in moarvm opcode specification 08:26
09:09 arnsholt joined
timotimo yo 09:12
brrt \o
timotimo anything much i have to change drastically in my translator code? 09:16
next thing on the to-implement list would probably be num registers/values and perhaps grabbing some constants from the moarvm headers (or perhaps i can just put them into the tree file verbatim?)
brrt if you require a constant, and it doesn't start with MVM_JIT, your best bet is the (&QUOTE) macro 09:23
because that simply reproduces the argument
no, it looks quite good. just that as i said (^params) takes no arg; the first list in a macro definition is not decoration, it's the argument list :-) 09:24
brrt wonders what would happen if people regularly decorated code with ornaments
timotimo oh, duh :) 09:25
i forgot to remove that
dalek arVM/even-moar-jit: 6da24be | timo++ | src/jit/core.expr:
throw out bogus argument list for ^params
 09:26
10:09 Ven joined 10:51 flussence joined 10:55 zakharyas joined
timotimo now that i've done a tiny contribution, i'm looking forward to the first generated and runned codes even more :D 11:07
brrt :-) 11:11
quite possibly heaps are still my favorite data structure 11:15
timotimo "quite possibly heaps", a probabilistic data structure 11:35
11:38 FROGGS_ joined
brrt :-) 11:41
12:10 _itz joined 12:13 colomon joined 12:18 colomon joined 12:27 zakharyas joined 12:29 colomon joined 12:31 colomon joined 12:40 colomon joined 12:59 leedo joined 13:01 brrt joined
timotimo i have no examples in the core.expr for num yet 13:01
do i just write (carg ... num)? 13:02
brrt yes
timotimo same for return type?
brrt yes
timotimo i don't think i really understood what you were trying to explain with regards to register addresses 13:05
gist.github.com/timo/afb0413f1aead.../revisions - looks nice, dunnit? 13:10
dalek arVM: f2ed167 | timotimo++ | tools/parse_jitgraph.p6:
literal 0 shall not confuse us
 13:11
arVM: 3240047 | timotimo++ | tools/parse_jitgraph.p6:
accept num parameters and return values
timotimo do we have anything like the bail statistics from the previous jit yet? to see how often we get to build chunks with the expr tree jit and how big they tend to become and what keeps them from being bigger? 13:13
brrt multiple values in a same register makes register allocation *hard* 13:16
no, but it's easy to get at
grep -i 'could not build an expression tree' 13:17
will get you all bail-lines
but one of my remaining goals is to release that restriction, that the whole basic block should be an expression tree
13:30 Peter_R joined 13:39 zakharyas joined 14:00 brrt joined 14:11 timotimo joined 14:17 colomon joined 14:18 Ven joined 14:30 colomon joined 14:32 Ven joined 14:46 pyrimidine joined 14:47 pyrimidine joined 14:48 rurban_ joined
timotimo seems like i have to go to an earlier commit to get a compileable moarvm 14:56
could it be that you forgot to check in some file, brrt?
./libmoar.so: undefined reference to `MVM_jit_register_free'
and such
the most common breaker of exprtree is decont when just -e 'say "hello"', which requires REG_ADDR to be handled 15:03
ah, and i have to strip the MVM_OP_ from the names that go into (template: ... ...) 15:04
when implementing the next best thing on the list, which was atpos_o i think or atkey_o or something, "ifnonnull" jumps to the top with quite a bit of lead: 151 ifnonnull vs 109 decont 15:06
gist.github.com/timo/afb0413f1aead..._hello-txt - here's the full tally after copy-pasting the whole preliminary tree output into the core.expr (and kicking out duplicates as well as trigonometric functions and sqrt) 15:13
is the length of the list in "tree roots" exactly how many instructions we're trying to build a tree out of? 15:21
longest i've seen is 9, but there's a whole lot of only 1 or 2 tree roots :S 15:23
null + set + goto; wow, the expr jit is going to optimize the F out of that! 15:47
16:03 Ven joined 16:20 hoelzro joined 16:38 colomon joined 17:11 Ven joined 17:41 Ven joined 17:53 TEttinger joined
masak .oO( there's no F in either of those words... ) 18:52
jnthn 3 19:13
oops
FROGGS :3 19:18
19:23 vendethiel joined
[Coke] masak: guess we're already done, then! 19:25
masak that was easy! 19:26
19:37 Ven joined 20:15 brrt joined
brrt good * 20:16
FROGGS hi brrt
brrt hi FROGGS 20:17
timotimo: no, did not forget to, that's just all NYI 20:18
unfortunately
i'm a bad developer!
timotimo don't worry :) 20:19
the branch isn't meant to be "shippable at any time!" ;)
brrt also, roots->ins map is somewhat subtle 20:20
yes, roots are now added for each instruction, so that by default the instruction order is maintained
timotimo i was just asking because that'd seem like a nice number to track growth with :)
brrt no, we do not need to keep it that way
yeah, it's a decent enough proxy
timotimo number of instructions per tree generated, that is
sometimes we even end up building a tree with 0 roots and nothing in it
brrt yes, i know, phi-only basic blocks 20:21
weird, huh
timotimo yeah
so the expr jit tries to build a tree from the beginning of a BB and aborts when it hits something it can't do and then wait until the next BB to try again? 20:22
brrt yes. and i want ot change that to a set of consumers
e.g. expr tree builder is a consumer, but args-and-invoke is also a consumer, and jumplist is also a consumer 20:23
20:23 zakharyas joined
brrt anyway, i'll be off now 20:23
i remain moderately hopeful of having a register compiler, and with that, a full fledged expr tree compiler, somewhere tomorrow or the day after that :-) 20:24
and then fix the bugs
see you!
jnthn brrt: Good luck with it! :)
brrt thanks :-)
it's been quite frankly harder going than i had expected. but i'm making progress, albeit uncompilable :-) 20:25
good luck with the SPW
brrt now really afk :-)
21:20 pyrimidine 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!