00:39 reactive-nick joined 00:40 itz_ joined 01:16 FROGGS_ joined 01:48 itz joined
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 ...
01:53 itz joined 03:48 cognome joined
sergot hi o/ 05:22
06:08 brrt joined
brrt \o 06:30
06:42 danaj joined 06:43 lizmat joined 07:15 brrt joined 07:30 zakharyas joined 08:00 lizmat_ joined 08:01 cognome_ joined, nebuchad` joined, ggoebel111111110 joined 08:02 pmichaud joined 08:03 lee joined 08:05 diakopte1 joined 08:08 betterwo1ld joined 08:11 synopsebot joined 08:39 kjs_ joined 08:44 Ven joined 09:10 itz_ joined 09:17 itz joined 10:02 ggoebel111111111 joined 10:24 Util joined
jnthn evening, #moarvm o/ 10:33
10:41 mj41 joined
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
11:24 Ven joined
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
14:19 ggoebel111116 joined
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
14:45 ggoebel111116 joined
carlin yip, my plan was to do realloc next if the malloc patch was okay 14:50
jnthn OK :)
carlin+
uh, carlin++
14:53 ggoebel111116 joined
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
:-)
15:20 ilbot3 joined, ashleydev joined 15:22 synopsebot joined, diakopter joined, carlin joined, [Coke] joined 15:27 donaldh joined
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
15:31 brrt left 15:40 ggoebel111117 joined, hatseflats joined 15:50 woosley joined, moritz joined 16:53 colomon joined 17:01 kjs_ joined 17:11 tgt joined 17:13 zakharyas joined 17:35 Ven joined
carlin github.com/MoarVM/MoarVM/pull/131 17:54
17:59 kjs_ joined
FROGGS carlin++ 18:12
18:31 Ven joined 18:53 ggoebel111116 joined 18:58 brrt joined 18:59 Ven joined
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
19:49 ggoebel111116 joined
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
20:00 ggoebel111117 joined 20:04 kjs_ joined
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
20:35 brrt left 20:41 colomon joined 20:45 rurban joined 21:07 Ven joined 21:09 kjs_ joined 21:44 ggoebel111117 joined
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?
22:12 kjs_ joined 22:19 FROGGS joined 22:25 Ven joined
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
22:58 colomon joined
carlin uint8_t flag = -1 makes flag = 255. and flag == -1 isn't true, flag == 255 is. 23:23
23:27 cognome joined
timotimo that's a bug, then 23:31
would you like to commit it or shall i do it for you?
23:34 cognome joined 23:37 Ven joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!