dalek arVM: dca7f4c | (Timo Paulssen)++ | src/jit/graph.c:
clearer error message for op_to_func's default case
01:50
arVM: 5c3d596 | (Timo Paulssen)++ | src/ (3 files):
make bigint_div and bigint_mod responsible for allocating
arVM: a10dc26 | (Timo Paulssen)++ | src/jit/graph.c:
jit div_I and mod_I.
timotimo can't sleep? why not code.
timotimo disappears into bed ...
sergot hi o/ 05:22
brrt \o 06:30
jnthn evening, #moarvm o/ 10:33
nwc10 good *, jnthn 10:42
or altnernatively 10:44
good GMT +08:00, jnthn
which really doesn't tell anyone anything useful
jnthn: in the profiler, I can't figure out how to get the call trace for rel2abs 10:46
carlin what should moar do if a {m,c,re}alloc fails? currently it just eventually segfaults/explodes 10:48
rurban it should GC imho 10:50
carlin so do a GC, retry the alloc, and then abort if it still fails? 11:03
jnthn "I should GC" => uh, no, you've absolutely no way of knowing you're at a safepoint. 11:12
*It
So that's infeasible.
Except in very specific situations.
nwc10 I was fearing this 11:13
jnthn Most certainly it doesn't make sense as a general rule.
The best general answer is to panic. We can look at specific situations where GC may help later. 11:18
nwc10 it's probably possible to panic to fd 2 including the size requested.
jnthn Yeah. Just don't try to allocate while doing so :) 11:19
nwc10 what could possibly go wrong? 11:20
jnthn dinner & 12:03
rurban All LISPs do a GC when the internal alloc fails. Usually trapped by libsigsegv, but this might be too difficult. A system malloc fail must panic though. 12:12
carlin I did this: gist.github.com/carbin/a2662ecad144ac930b76 14:25
jnthn carlin: Why xmalloc? 14:34
carlin xmalloc is usually used for a malloc that aborts on failure 14:40
FROGGS_ because of the exception? :D
carlin easy enough to make it just malloc though
FROGGS_ I guess the name MVM_malloc would already imply some sort of extra work/check 14:41
carlin fair enough 14:43
if the patch is good otherwise I can change that
jnthn Yeah, I think I'd prefer juts MVM_malloc
*just
Should probably do MVM_realloc and MVM_free while at it. 14:44
carlin yip, my plan was to do realloc next if the malloc patch was okay 14:50
jnthn OK :)
carlin+
uh, carlin++
carlin also I have a few pull requests open that I was hoping someone could look at 14:54
brrt hmm yeah post 'm i'd say 15:03
:-)
carlin github.com/MoarVM/MoarVM/pull/119 and github.com/MoarVM/MoarVM/pull/126 15:29
I also have 2 others where I fixed some warnings but those are the two I care most about
jnthn OK. I really need to sleep now...so jetlag. :) I'll look at them tomorrow.
carlin sure, g'night :) 15:30
jnthn 'night o/
brrt 'night 15:31
carlin github.com/MoarVM/MoarVM/pull/131 17:54
FROGGS carlin++ 18:12
brrt finally sees that his implementation of div_i is basically wrong 19:10
and ehm 19:12
the same is kind of true about mod_i
since mod_i with a zero divisor causes SIGFPE just as div_i
m: nqp::mod_i(4, 0); 19:13
camelia rakudo-moar cb1d0e: OUTPUT«(signal )»
brrt uhm, is this implementation of div_i for real 19:26
timotimo :S 19:31
brrt seriously.. is there even a quick way to implement that branch 19:42
(i suppose there is, but still)
timotimo no clue :(
jnthn is very busy with daywork things? 19:43
brrt jnthn is in china and understandably has jetlag :-) 19:44
timotimo ah, of coruse 19:45
brrt basically 19:50
we decrement the quotient if these conditions are met
either the denominator or the numerator is negative 19:51
and the remainder is zero
ok, i can manage that
it will take all registers i've got, but still
't can be done 19:57
brrt argh much difficult 20:07
timotimo :( 20:08
brrt it is my own fault, of course
trying to be 'efficient'
timotimo :)
branchless
etc
brrt tsja 20:09
i mean
yes
oh, darn, i see what's going wrong 20:15
pls hlp me out 20:19
basically, i'd really need to check if the original numerator was lower than zero, but by the time i've done the division, it is replaced by the quotient because that's just the limitations x86 puts on divison 20:20
however, the rule is: (num < 0) ^ (denom < 0) & (remainder != 0)
timotimo so branch on the divisor first? :P
brrt NO BRANCHES FUUU
:-p
i'm pretty sure we can replace this with correct branchless code 20:21
i /do/ still have the denominator, since it must be in another register (rcx, that is)
so.... if the denominator is lower than zero, and the quotient is lower than zero, then the numerator must have been greater than zero 20:22
in which case our thingy holds
our rule
in fact.... 20:24
if the quotient is negative, then either the denominator or the numerator must've been negative,so the condition holds 20:28
so it is better phrased as: (quotient < 0) & (remainder != 0)
and... this is correct, it seems 20:30
so yay
FROGGS much yay? :D 20:31
brrt very 20:32
dalek arVM: 5b574f8 | (Bart Wiegmans)++ | src/ (2 files):
Fix negative division in JIT

Also fix divide-by-zero in mod_i, since mod_i is implemented by signed division anyway (and n % 0 has no mathematical sense).
20:35
brrt afk
carlin github.com/MoarVM/MoarVM/blob/mast...ame.c#L961 21:46
flag is unsigned, so so it can't be -1 and that if will always be true?
timotimo hm, i wonder if C will consider -1 to be == to what flag ends up being when you assign -1 to it 22:41
hoelzro doesn't == cast to signed if one of the sides is, or something? 22:43
timotimo good question 22:44
we could just turn flag into a MVMint16 instead of guessing
worst case it's undefined behavior we're relying on ... but probably not 22:45
carlin uint8_t flag = -1 makes flag = 255. and flag == -1 isn't true, flag == 255 is. 23:23
timotimo that's a bug, then 23:31
would you like to commit it or shall i do it for you?