|
00:34
hoelzro joined
01:52
FROGGS_ joined
05:51
woolfy joined
06:11
lizmat joined
06:41
FROGGS joined
07:08
lizmat joined
07:11
zakharyas joined
07:16
brrt joined
07:36
brrt joined
08:35
donaldh joined
09:00
brrt joined
09:29
brrt left
|
|||
| dalek | arVM/loop_labels: 0215c7d | (Tobias Leich)++ | lib/MAST/Nodes.nqp: align naming of attrs of MAST::HandlerScope to MVM_HandlerScope |
09:36 | |
|
10:05
mj41 joined
10:13
lizmat joined
10:26
donaldh joined
|
|||
| dalek | arVM: 17b40b8 | jonathan++ | src/core/interp.c: Extra NULL checks in spesh guard ops. In theory we never get a real NULL here, only ever a (safe) VMNull. But there are places that don't make that transformation for us yet, so for now be very careful. |
10:37 | |
|
10:40
lizmat_ joined
11:43
odc joined
11:47
lizmat_ joined
11:48
lizmat_ joined
12:17
LLamaRider joined
12:22
mj41 joined
12:24
btyler joined
13:21
cognominal joined
13:33
jnap joined
|
|||
| dalek | arVM: e9d625d | jonathan++ | docs/ChangeLog: Add ChangeLog for 2014.05. |
13:34 | |
| jnthn | We did some work :) | ||
| FROGGS | hehe | ||
| that is a lot :o) | |||
|
13:37
cognominal joined
|
|||
| timotimo | + Ops to for 32/16 bit 64 int literals and isnonnull, plus use in compiler | 13:40 | |
| that's pretty awkwardly formulated, or i have a brainfart? | |||
| + turn islist/... into either isnonnull or a literal 0. | |||
| is a duplicate of: | |||
| jnthn | timotimo: Just patch it ;) | ||
| timotimo | + Optimize islist/isnum/... in spesh | ||
| i guess i will :) | |||
| fixing now | 13:42 | ||
| dalek | arVM: 209d041 | timo++ | docs/ChangeLog: unawkward sentences and dedupe a change |
13:44 | |
|
13:49
jnap joined
|
|||
| jnthn | I'll likely cut release later on today | 14:11 | |
| So it's done in good time | |||
| nwc10 | jnthn: you'd prefer to hold off on the struct re-ordering patches? | ||
| jnthn | nwc10: How risky are they? | 14:12 | |
| nwc10 | I didn't think that *they* were risky. | ||
| jnthn | OK | ||
| nwc10 | if they build for you on Win32 (64 and 32) I think everything we know is good is (pretty much) covered | ||
| jnthn | That was my cut feeling too | ||
| *gut | |||
| nwc10 | the other things I'd like to do, they are more risky. | 14:13 | |
| so not "This Week" :-) | |||
| jnthn | applied them all locally | 14:18 | |
| building and testing now | |||
| nwc10 | cool thanks | 14:21 | |
| oh, curious, compare "Architecture" on packages.debian.org/jessie/rakudo packages.debian.org/jessie/nqp and packages.debian.org/jessie/parrot | 14:24 | ||
| jnthn | Curious indeed | 14:26 | |
| nwc10 | parrot additionally builds on "mips", "powerpc" and "s390x" | ||
| jnthn | mips, powerpc and s390x missing for Rakudo/NQP comapred to Parrot | ||
| We know MoarVM builds Rakuod on PowerPC | |||
| *Rakudo | 14:27 | ||
| dalek | arVM: c6be74d | nicholas++ | src/6model/reprs/MVMCompUnit.h: Re-order members of MVMCompUnitBody to avoid alignment holes. Saves 4 bytes on ARM and x86, 32 bytes on x86_64. |
14:36 | |
| jnthn | nwc10: Applied them, thanks | ||
|
14:37
dalek joined
|
|||
| nwc10 | cool, thanks | 14:37 | |
| tadzik | hmm, shouldn't MVMuint32 go after all the 64bit fields, preferably? | ||
| well, after the pointers, which may be 32 or 64 | 14:38 | ||
|
14:38
brrt joined
|
|||
| nwc10 | maybe, but find me a platform with holes now :-) | 14:38 | |
| tadzik | ah, there are two 32s in a row | ||
| nevermind then :) | |||
| I was thinking about num_frames in the first diff | |||
| but it has MVMuint32 data_size; just above it in the code | 14:39 | ||
| so no holes :) | |||
| wow, that's a lot of patches | |||
| nwc10++ | |||
| brrt | \o #moarvm | 14:45 | |
| FROGGS | hi brother | ||
| jnthn | brrt \o/ | ||
| FROGGS | err | ||
| hi brrt | |||
| brrt | :-) | ||
| FROGGS | :o) | ||
|
14:45
btyler joined
|
|||
| brrt | hows things here? i've seen lots of talk of nwc10's patches | 14:45 | |
| jnthn | They got in :) | 14:46 | |
| Things are fine | |||
| brrt | then i'll pull and check out | ||
| jnthn | Release 2014.05 within next 24 hours | ||
| brrt | i think dynasm has explicit support for struct access, i should check that out | 14:47 | |
| oh, nice | |||
| (time flies /so/ fast, and moarvm goes /so/ fast too) | |||
| jnthn | How many releases until JIT? :D | ||
| brrt | well.... optimistic me thinks that 2014.07 should be doable? | 14:48 | |
| jnthn hopes so :) | |||
| brrt | based on the following characteristics: | ||
| dynasm is really awesome (i'm cooking on another post concerning dynamic labels, dynamic registers, struct access) | |||
| moarvm bytecode set is ... acceptably large (haven't counted, but there doesn't seem to be hundreds of them) | 14:49 | ||
| moarvm bytecode set can also be conceptually be divided between machine-like instructions and function-call-like-instructions | 14:50 | ||
| and i'm planning to use that distinction to good effect (i.e. instruction selection / register allocation algorithms can 'ignore' function-call like operations | 14:51 | ||
| jnthn | brrt: Yes, I had imagined we'd compile many of them into function calls to the functions the ops themselves call | ||
| brrt | thats what i had imagined | 14:52 | |
| i had also imagined a 'cheat code' :-) | |||
| jnthn | brrt: And if there are any ops with a big body that ain't interesting to JIT, we can move their logic to a function. | ||
| which'll shrink the interp too :) | |||
| brrt | i.e. compile interp.c to asm using gcc (with intel syntax) -> text-transform all labels into dynasm instructions -> compile -> profit | ||
| that seems like a plan too | 14:53 | ||
| (which was actually my goal for 'core-ified' moarvm bytecode in my original proposal) | |||
| (:o empathy just cleared my entire chat window for no reason) | 14:55 | ||
| jnthn | I feel your pain, man... :P | ||
| FROGGS | hehe | 14:56 | |
| brrt | OT: i like it as a a casual chat client (good gnome offline / online support) but this was... weird | ||
| FROGGS | I have sometimes problems with my old icq profile in empathy, I do not see recent messages | 14:58 | |
| brrt | do you still use icq? | 14:59 | |
| jnthn | brrt: No... | 15:02 | |
| gotta go, bbl | |||
| brrt | :-) | ||
| FROGGS | brrt: only because of one person, so the message count is quite low :o) | 15:12 | |
| brrt | i see | 15:13 | |
| but missing a message would be annoying | |||
| is icq peer-to-peer? who still runs that :-o | |||
| FROGGS | no idea... | 15:14 | |
| I see the tooltip of the message, and empathy is also highlighted in my starter, so I sort of see that there must be something :o) | 15:15 | ||
| bbiab | |||
|
15:17
btyler joined
|
|||
| brrt | oh, bbl = be back later | 15:19 | |
| that, too | |||
|
15:35
FROGGS joined
15:48
mj41 joined
16:04
btyler joined
16:27
FROGGS[mobile] joined
17:08
vendethiel joined
17:25
mj41 joined
17:55
brrt joined
17:56
btyler joined
|
|||
| dalek | arVM: ce948e1 | (Tobias Leich)++ | / (6 files): make exception handlers aware of labels Frame handlers have now a register which can hold a label in case we have a labeled loop. When an exception is thrown and the category is MVM_EX_CAT_LABELED, we check for object identity of the thrown payload and the label in the register. That means we will have handlers for e.g. 'redo', and this handler will care about 'redo' exceptions without a label, and also will care if the label fits. |
18:43 | |
|
18:45
btyler joined,
mj41 joined
19:11
mj41 joined
21:25
btyler joined
21:29
donaldh_ joined
21:35
lizmat joined
|
|||
| timotimo | so, cgoto is done with env CGOTO=1 make? | 21:44 | |
|
22:25
dalek joined
22:28
lee__ joined
22:29
retupmoc1 joined
22:31
brother joined
22:32
JimmyZ_ joined
22:34
donaldh__ joined
22:36
__sri joined
22:37
hoelzro_ joined
22:43
lizmat joined
22:47
btyler joined,
lizmat joined
|
|||
| jnthn | timotimo: Argument to make, I think | 22:47 | |
| timotimo | oh, darn | 23:04 | |
|
23:05
woolfy joined
23:13
colomon joined
|
|||