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
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
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
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
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
brrt :-) 11:41
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
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
masak .oO( there's no F in either of those words... ) 18:52
jnthn 3 19:13
oops
FROGGS :3 19:18
[Coke] masak: guess we're already done, then! 19:25
masak that was easy! 19:26
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
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 :-)

Powered by Cro and the Raku® Programming Language.

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

Thank you!