01:32 lizmat joined 04:19 Peter_R joined 05:26 lizmat joined 05:43 Peter_R joined 06:12 FROGGS joined 06:57 zakharyas joined 07:09 brrt joined
timotimo you know ... 07:43
one of the most amazing achievements of RPython and PyPy is that its traces go very deep into its guts
does it make any sense whatsoever to build some representation of what some of our internal functions do so that their insides could be traced as well? 07:44
that'd be three to five steps ahead of what we currently do when we devirtualize reprops or turn accesses to objects into direct memory offsets 07:45
brrt hmm
i've thought about that
there are roughly two ways to go about it
timotimo build our own C compiler!
brrt a): read the debugging information 07:46
that'll tell you what-means-what
b): disassemble the machine code
c): some combination of a and b perhaps using tcc or something
timotimo trying to disassemble the machine code gcc, clang and msvc spit out seems like a gigantic task 07:47
especially since they have a ridiculous amount of cleverness
in any case, that idea can most probably be shelved until much, much later 07:48
if i want to build something helpful, i'd probably best finally build that tool that roughly picks jit/graph.c apart into some re-usable data format 07:49
brrt hmmm
timotimo and/or perhaps look at the code-gen problem about local/localref where a decont appears out of thin air
brrt if you would do that, i would be very very very grateful
it's actually my work, of course :-) 07:50
timotimo and/or figure out what's keeping the if/unless + not_i/so_i from working
brrt anyway, dissassembling x64 machinecode is tricky but not undoable
timotimo i'd love to contribute to your work; if i can get rid of some rote work and you can concentrate on architecting and stuff, that'd be great 07:51
you can't undo it? ;)
brrt considering that you 'know' which things are calls, branches, returns
timotimo hm, well, i guess
brrt you can pretty reliably figure out what constitutes a function
lol, no, ehm, i meant it's doable
timotimo :)
brrt ok, one of the things i think should be automatable, is conversion of your routine function call to exprlist format 07:52
letmegetanexampleofthat
timotimo extract only the branches and turn it into an exprlist like "copy-paste this part of the already existing machine code here, build this branch, more machine code copied from here to there, a label, ..."? 07:53
brrt gist.github.com/bdw/8ed7638d265ff77d716e 07:56
this would be an example
the args[] thingy can be converted to the arglist 07:57
each item represents a carg
timotimo oh
you're talking about graph.c to output format
brrt hey, i didn't say it was easy
:-P 07:58
timotimo no problem, that'll be doable
brrt anyway, i don't want to dump this into your lap. only pick it up if you want it
more difficult stuff, you can just bail out on; they can be converted by hand if necessary 07:59
but there are a lot of these, and they all follow the same pattern 08:00
timotimo mhm 08:01
brrt you don't have to worry about the actual operand values, because the tree builder takes care of that 08:02
another thing is, if you have a register you're writing to, (say wval), you can neglect that, too 08:03
because the tree builder is responsible for that, too
timotimo the destination register? 08:04
brrt yes
neglect it
throw it to the wind
timotimo as in, what is -1 in your "from.c" example
brrt :-)
can be ignored
timotimo so i'll just convert the JIT_RV_* for the last argument of "call"
brrt yes, i think so 08:05
timotimo mhm, fair enough
brrt for the last argument of carg, i think you can get away with just using ptr or int for most cases
doesn't make a difference for us 08:06
timotimo mhm 08:07
brrt the num thing does make a difference. but it' might be tricky to detect
actually, it's not so difficult, reg_val_f => num, otherwise, perhaps just use int?
timotimo "just use int" %) 08:10
so, still like in your example, then?
"carg $foo num" 08:11
rakudo already noms 3 gigs of ram before it even reaches the beginning of op_to_func ... i'm searching for it via .*? 08:20
what the ...
anyway, i've got to be off for a bit
08:23 Ven joined
brrt see you :-) 08:33
i'd... ehm... heretically suggest using perl5. but that's your business, of course :-)
aargh why didn't i just finish it yesterday 08:51
brrt bbiab
09:23 zakharyas joined 09:28 brrt joined 10:24 Ven joined 10:43 JimmyZ_ joined
timotimo i can't even perl5 10:53
aaah very clevre 12:07
clever
make a "rule ws"
masak really `rule` and not `token`...? 13:23
jnthn masak: That's why it was "clever" :P
masak "clever (adj.) -- ... (9) not clever. ..." 13:24
:P
13:28 brrt joined 13:30 arnsholt joined
brrt \o 13:32
timotimo oO 13:33
jnthn /o 13:34
brrt :-) 13:36
FROGGS o|) »--> (·) 13:40
o|) (·) __ 13:42
damn it
jnthn lol 13:43
masak it actually takes some skill to miss when there's just one dimension :P 14:10
14:45 danaj joined
brrt hmm 14:59
jnthn hmm? 15:07
brrt i wsa overly optimistic yesterday evening :-( 15:11
*was 15:12
15:15 Ven joined
brrt the trick, i think, is to reduce the amount of possible label sets 15:16
e.g. the combination of labels that are possible 15:18
let me think about that a bit more
15:24 FROGGS joined 15:30 njmurphy joined 15:49 avuserow joined 16:12 brrt joined
nwc10 timotimo: not sure if you'd seen this: blogs.perl.org/users/flavio_s_glock...hmark.html 17:31
currently his codegen beats Rakudo's (and MoarVM's ability to spesh it) 17:32
I'd love someone more competant than me to work out how to beat his code.
17:37 lizmat joined
timotimo it doesn't do big integer semantics 17:41
are you measuring against "my int $i" and such?
nwc10 at jnthn's suggestion yesterday I tried that too. He still wins. 17:43
jnthn How to get faster: lexical to local lowering, scope elimination, escape analysis (capable of understanding loops), scalar elimination, induction variable stuff to optimize away the bigint upgrade checks, and then good machine code generation. 18:04
timotimo right, i want the lexical to local lowering to work again 18:05
really, really want :)
but wanting something doesn't magically make you capable of bringing it about …
jnthn: do you have a hunch for where a decont may be generated that doesn't explicitly mention "decont"?
also, does the mast compiler that's inside moarvm ever add stuff like that? 18:06
jnthn It adds them in response to :decont annotations in the mapping stuff
timotimo mhm
that's for inbound parameters, yeah? not for outbound? 18:07
jnthn Right
timotimo hmm
jnthn The lexical to local lowering is competing with getting multi-dim stuff done, getting the new S17 additions in place, squishing concurrency bugs, and probably will have to compete with whatever GLR task stealing is needed of me. 18:08
timotimo mhm
timotimo has dinner 18:17
18:32 lizmat joined 18:49 brrt joined
brrt ooh, that's fairly cool 18:54
timotimo hm? 18:55
dalek arVM: c9d526f | moritz++ | docs/ChangeLog:
Fill in some ChangeLog for 205.07
 18:57
brrt the perl5-to-java compiler 18:58
question is, of course, how well does it work 18:59
i think it's a static compiler, from the looks of it?
timotimo yeah, if it's anything like the rest of perlito 19:00
it is still perlito, right?
brrt aye
well, that's still really cool 19:01
the thing that puzzles me personally is how he creates good code for a stack machine 19:03
stack machines are weird
hmm 19:07
ok, observation: most tilish things can be evaluated postorder 19:09
some things cannot (if statements)
however... some if statements are really good statements for tiling
timotimo it could be it creates java code rather than java bytecode? 19:10
brrt e.g. (if (all (foo) (bar)) (quix) (quam)) <- clearly if foo is false we can skip ahead directly to quam
jnthn timotimo: I think it does, yes 19:11
brrt oh, yes, right :-) 19:13
19:14 zakharyas joined 19:15 vendethiel joined
brrt how does it deal with e.g. eval statements 19:20
or does it just include the compiler for that purpose
hmm 19:21
actually, it's not that simple of course
jnthn One of the more annoying things about targetting Java instead of JVM bytecode is "no goto2 :) 19:22
timotimo mhhh
every basic block becomes a method
and your lexpad becomes an object 19:23
moritz rakudo with moarvm master has quite a few spectest failures, and t/spec/integration/advent2014-day05.t hangs
not a good day to cut a release :(
timotimo it *could* be one of my recent merges made that happen
hm, no
i didn't really do much 19:24
brrt what's goto2?
jnthn goto, followed by a typo'd " :P 19:25
moritz huh, hangs on recommended moar version too 19:27
moritz could have sworn he (mostly successfully) spectested today 19:28
oh, my rakudo wasn't quite up to date
but it really seems test changes that broke so many of them for me 19:39
timotimo test changes broke tests? 19:43
dalek arVM/even-moar-jit: 3f60420 | brrt++ | src/jit/x64.tiles:
Add file describing intial grammar of tiler

I have yet to figure out how to practically map it to machine code, but it's a start.		 19:46
brrt ok, hope that may break me out of my impasse :-) 19:53
still many things i'm not sure of
but i'll manage eventually
20:03 ggoebel joined 20:57 TEttinger joined 21:49 Peter_R joined 23:33 jnthn joined, [Coke] joined, sergot joined, moritz 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!