|
00:32
ggoebel joined
02:48
ilbot3 joined
03:19
ggoebel joined
06:47
ggoebel joined
07:27
domidumont joined
07:31
domidumont joined
07:42
brrt joined
|
|||
| brrt | \o #moarvm | 07:43 | |
| nwc10 | o/ | 07:47 | |
|
07:58
TimToady joined
|
|||
| brrt | \o nwc10 | 08:10 | |
| decision time | |||
| I have two loops in linear scan which are very similar; they take live ranges in ascending-first-use order, maintain a list of active live ranges, expire registers when they are out of scope, etc. | 08:13 | ||
| one of them is for *proving* that all values can fit into a register (and for modifying the code so that this holds true) | 08:14 | ||
| the second is for assigning registers | |||
| i thought initially that these were going to be very distinct loops, but they are not | |||
| I can roll them into one, but at the cost of complexity | |||
| (one specific example of complexity: if it happens that one live range wants a register that is already handed out, I have to swap them, which is not in itself that hard, but I may have to update the references-to-that-live-range too) | 08:15 | ||
| actually, I don't have to do that... I can still resolve the references to live ranges in the second loop | |||
| while rolling the register assignment into the first loop | 08:16 | ||
| hmm, hang on, it doesn't entirely work so easily | |||
| .... let me think for a bit | |||
| nope, assign-then-spill never really runs into trouble | 08:18 | ||
| dalek | arVM/even-moar-jit: bf9bf84 | brrt++ | src/jit/linear_scan.c: Copy register ring from old allocator Have to think for a bit about the roles of the two loops and when register assignment ought to be done. |
08:25 | |
|
08:31
zakharyas joined
|
|||
| nine | brrt: is this code that's pretty much done or is it likely or at least possible that it will change? | 10:39 | |
| brrt | ehm... not sure how you mean | 12:53 | |
| but I think I can give an answer | 12:54 | ||
| except for the bit I was going on about this morning, I'm fairly sure I have the gist of the algorithm now | |||
| i won't be replacing it with another algorithm with wildly different characteristics | 12:55 | ||
| I'm intending to change a few bits on the layout of the MVMJitTile structure | 12:56 | ||
| so that is a yak that needs shaving | |||
| but except for the register assignment element, the algorithm works | 12:57 | ||
| I think I had best rolled register assignment into first 'main' loop, and do the tile-to-register filling latest | |||
| so in a final loop | 12:58 | ||
| that has the least complexity, both in terms of code and runtime | |||
| also, I have a blog post coming up about the way linear scan works and why, so I can't go and change it now :-) | 12:59 | ||
| however.... | |||
| I'm currently not handling things like different register classes and pre-coloring | |||
| i intend to 'merge' the linear scan allocator in before I do that | |||
| once that is done, I'm sure that both aliases and conditional paths will be handled well | 13:00 | ||
| so I can start testing the compiler with those features | 13:01 | ||
| and when that is done, I can start on the specific register requirements | |||
| I have a design for that as well | |||
|
13:20
ggoebel joined
|
|||
| brrt | once register requirements are done, I expect actual function calls to be comparatively easy | 13:30 | |
| dalek | arVM: b4cd2a6 | jnthn++ | src/6model/serialization.c: Don't reveal partially deserialized method cache. Otherwise, we can end up handing back incomplete and bogus results. |
14:08 | |
| arVM/rehash: aeff0ec | jnthn++ | src/6model/reprs/MVMHash.h: Remove a couple of now-unused macros. |
15:25 | ||
| arVM/rehash: c793606 | jnthn++ | src/6model/reprs/MVMHash.h: Remove unused macro parameter. |
|||
| arVM/rehash: 8a10e9c | jnthn++ | src/6model/reprs/MVMHash.h: Eliminate a layer of macro. It didn't really add anything useful, and just made it harder to see what was going on. |
|||
|
15:31
pyrimidine joined
|
|||
| dalek | arVM/rehash: cb496e0 | jnthn++ | src/6model/reprs/MVMHash.h: Use key/value instead of name/entry. |
15:52 | |
| arVM/rehash: 4e10db5 | jnthn++ | src/ (13 files): Factor flatten calls into a handful of codepaths. This leaves all uses of MVM_string_flatten that relate to hashes in just three macros, which will ease the transition away from them. |
|||
|
16:08
pyrimidine joined
16:10
pyrimidine joined
|
|||
| dalek | arVM: 4c9fd00 | timotimo++ | src/core/interp.c: give a bunch of exception ops repr and debug name output |
16:48 | |
| arVM/rehash: bb91104 | jnthn++ | / (7 files): Eliminate MVM_EXTRACT_HASH_KEY. This futher unifies access to hashes based around MVMString * keys, so they now always go through MVM_HASH_GET and MVM_HASH_BIND. As well as being a nice code cleanup, it also will make it far easier to remove use of `MVM_string_flatten`. |
16:54 | ||
| timotimo | <3 | ||
|
16:54
pyrimidine joined
16:55
ggoebel joined
|
|||
| dalek | arVM/rehash: 37d3be7 | jnthn++ | .gitignore: Add .swp to editor backup .gitignore files. |
16:56 | |
|
16:57
pyrimidi_ joined
|
|||
| jnthn | Time for a break. :) | 17:06 | |
|
17:14
xtt joined
|
|||
| xtt | Hello everyone, I am a new comer and want to ask if there is any manual writing code in MoarVM like PIR? I am not sure if this is a valid question because the info about perl6/moarvm/parrot/etc i could get is so ambiguous... | 17:20 | |
|
17:20
vendethiel joined
|
|||
| mst | xtt: I'm not sure if it's a valid question because moarvm is a completely different system to parrot | 17:24 | |
| xtt: take a step back and explain what originally led you to ask the question? | |||
| timotimo | it's unlikely that you want to write Moar bytecode like you would PIR. you'd most probably write either MAST from nqp, or even QAST | 17:29 | |
| timotimo AFK for a couple of minutes | |||
|
17:35
vendethiel joined
|
|||
| timotimo | ok, i'm back | 17:38 | |
| xtt: anything in particular you want to know? | |||
| xtt | I want to understand (1) moarvm's syntax (like PASM/PIR?) (2) npq's syntax and (3) which docs should I begin with | ||
| btw I have no experience in low-level programs... I usually write HLLs, so it's kind of a trouble to me. | 17:39 | ||
| timotimo | the closest you can get to low level moar bytecode is writing MAST in an NQP program and using the mastcompiler that's built into moarvm to compile it to .moar files | 17:41 | |
| lizmat | xtt: maybe github.com/edumentab/rakudo-and-nq...als-course is something to look at ? | ||
| xtt | lizmat: Wow i think this is what i need | 17:43 | |
| timotimo: mst: lizmat: Thank you all for helping me! I will start with lizmat's advice first. | 17:44 | ||
| timotimo | sure | 17:45 | |
| feel free to stay in the channel and ask further questions | |||
| lizmat | xtt: have the appropriate amount of fun! :-) | ||
| xtt | Ok i will. it's exciting to get involved with such project | 17:46 | |
|
18:00
xtt joined
18:05
domidumont joined
18:12
FROGGS joined
20:50
pyrimidine joined
21:42
pyrimidine joined
22:32
pyrimidine joined
22:42
pyrimidine joined
22:52
pyrimidine joined
22:58
pyrimidine joined
23:20
pyrimidine joined
23:41
pyrimidine joined
23:51
pyrimidine joined
|
|||