00:15
vendethiel joined
01:53
colomon joined
01:54
vendethiel joined
02:16
xiaomiao joined
02:28
colomon joined
04:40
harrow joined
05:09
skids joined
|
|||
skids | TWIMC, while reading through moarvm source I was left wondering if there shouldn't be a return before line 52 of src/core/coerce.c | 05:12 | |
05:15
skids left
05:43
FROGGS joined
|
|||
TimToady | you could be right, since flip is otherwise done twice, apparently... | 05:44 | |
btw, it took me far too long to figure out you meant a return statement rather than a carriage return :) | 05:45 | ||
dalek | arVM: 2d26914 | FROGGS++ | VERSION: update version to 2015.05 |
06:04 | |
FROGGS .oO( slow cl.exe is slow ) | 06:06 | ||
dalek | arVM: eae763b | FROGGS++ | ports/macports/Portfile: Update macportfile to 2015.05 release |
06:29 | |
FROGGS | jnthn: tarballs are at: | 06:36 | |
froggs.de/perl6/MoarVM-2015.05.tar.gz.gpg - and - froggs.de/perl6/MoarVM-2015.05.tar.gz | 06:37 | ||
[Coke]: please review github.com/MoarVM/MoarVM/commit/eae763b653 and trac.macports.org/ticket/47803 | 06:38 | ||
07:24
Ven joined
07:37
zakharyas joined
09:01
danaj joined
09:09
FROGGS joined
11:00
Ven joined
|
|||
jnthn | FROGGS: Both of those files are now in moarvm.org/releases/ | 11:36 | |
FROGGS | jnthn++ | ||
12:03
Ven joined
|
|||
Ven | .tell brrt interesting piece of JIT code in LuaJIT github.com/LuaDist/luajit/blob/mas...t_narrow.c | 12:04 | |
no tell here? | 12:07 | ||
FROGGS | it only lives in one channel | 12:09 | |
12:18
lizmat joined
|
|||
[Coke] | FROGGS++ - nice!, thanks. | 13:03 | |
FROGGS | macports++ # trac.macports.org/changeset/136582 | 13:50 | |
[Coke] | wow, that was quick. | 13:51 | |
wonder if my +1 helped. | |||
FROGGS | quite possible | ||
[Coke] | I'm all for me expending that little effort! ;) | 13:55 | |
FROGGS++ again. | |||
FROGGS | [Coke]: so you want to get nqp into macports next? | 13:56 | |
[Coke] | Yes, that's the plan. It's slightly harder since we want to have both nqp-moar and nqp-jvm. | 13:57 | |
I honestly got distracted by $dayjob. | 13:58 | ||
FROGGS | yeah | 13:59 | |
14:29
lizmat joined
14:50
FROGGS joined
15:33
brrt joined,
Ven joined
|
|||
brrt | \o | 15:33 | |
15:35
skids joined
|
|||
brrt | Ven: interesting piece, yes | 15:36 | |
15:36
Ven_ joined
|
|||
brrt | of course, we have real integers, unlike luajit | 15:37 | |
and iterators | |||
so we need quite a bit less speculation and brilliance than luajit does | |||
jnthn | Well, or at least *different* speculation and brilliance. :) | 15:38 | |
brrt | what we do need (or want) is the ability to strength reduce Int to int | ||
right, i meant for dealing with numbers only :-) | |||
jnthn | Well, a good first step is to generate assembly for the fast path with a fallback | 15:39 | |
(e.g. the non-big-int case) | |||
I think the expr tree stuff will make that a load easier to implement. | |||
brrt nods | 15:40 | ||
skids | TimToady: wrt backlog: without the return statement it also accesses "result" unitialized... to no real consequence, but... surprised no tools caught that. | ||
jnthn | Indeed | 15:43 | |
brrt | coerce_istrue is quite funky though | ||
jnthn | Replacing the break; with a return; is likely the best fix | ||
(rather that duplicating it in the branches) | |||
brrt | it's not necessarily broken though | 15:45 | |
because the result is written to an address, that happens after the boolification method returns | |||
and the flip is only applied then | |||
skids | right. Minus some weird racey thing it shouldn't be producing incorrect results. | 15:46 | |
brrt | currently it just writes either 0 or 1 or garbage to the register, and only then the interpreter executes the callee frame, which writes the correct value to the register | 15:47 | |
brrt nods | |||
but yeah, it looks rather wrong, i grant that | |||
and it can be a problem if something 'clever' starts happening to these registers in the meantime | |||
not sure what that would be | |||
but it's possible | |||
now that we're talking about it... when is MVM_coerce_istrue ever actually called with true_addr, false_addr, and would it cost much to eliminate that possiblity and just use a branch-and-goto instead | 15:48 | ||
dalek | arVM: d3c3bd4 | jnthn++ | src/core/coerce.c: Fix control flow fail; skids++. |
15:49 | |
jnthn | brrt: if_o and unless_o I suspect | ||
brrt | hmm | 15:50 | |
skids off to Mad Max, out of some strange sort of sense of obligation to see it. | 15:52 | ||
jnthn | They exist as much for keeping code size down as anything. | ||
15:53
skids left
15:59
brrt joined
|
|||
FROGGS | jnthn: can you delete the .gpg file and upload this one? froggs.de/perl6/MoarVM-2015.05.tar.gz.asc | 16:01 | |
jnthn: though, no hurry of course | |||
jnthn | FROGGS: done | 16:02 | |
brrt | well, if_o and unless_o can still be implemented, that is no problem at all | ||
(my connection will continue to be flaky in the coming hours) | |||
oh, i'm wrong | |||
never mind | |||
darn | |||
if you boolify by method call, then surely you can't branch upon the result | |||
brrt wonders what it'd take to kill if_o and unless_o, and whether it'd be worth it | 16:07 | ||
(why insist on killing them? because they bring significant complexity (a full type for the method call version) for very little benefit imho | 16:08 | ||
the JIT translates them to istrue anyway | 16:10 | ||
but it does require another register | 16:14 | ||
by the way | 16:17 | ||
what does the VM macro expand to | 16:19 | ||
brrt off for now | 16:28 | ||
16:28
brrt left
|
|||
jnthn | "the VM macro"? | 16:32 | |
FROGGS[mobile] | or is it the macro "expand to"? | 17:03 | |
such possibilities! | 17:04 | ||
18:41
oetiker joined
18:52
TimToady joined
19:09
FROGGS joined
20:02
FROGGS joined
20:51
FROGGS joined
22:48
FROGGS joined
|