dalek arVM/loop_labels: 0215c7d | (Tobias Leich)++ | lib/MAST/Nodes.nqp:
align naming of attrs of MAST::HandlerScope to MVM_HandlerScope
 09:36
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
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)
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
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
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
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)
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
brrt oh, bbl = be back later 15:19
that, too
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
timotimo so, cgoto is done with env CGOTO=1 make? 21:44
jnthn timotimo: Argument to make, I think 22:47
timotimo oh, darn 23:04

Powered by Cro and the Raku® Programming Language.

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

Thank you!