|
01:13
lizmat joined
01:47
ilbot3 joined
02:14
lizmat joined
04:13
lizmat joined
05:19
lizmat joined
07:37
lizmat joined
07:44
lizmat joined
|
|||
| JimmyZ | hmm, it'd be nice p6bigint take 64bit as small int, intead of 32bit | 08:19 | |
| timotimo | if you can make it happen, i'd be +1 | ||
| ShimmerFairy | I thought it did already, for 64-bit arches of course. Huh. | 08:20 | |
| timotimo | we had to have a flag somewhere in the p6int that differentiates | 08:25 | |
| nwc10 | you can probably do 63 bit int, and use the bottom bit as a flag, assuming that pointers are better than 2 byte aligned. | 08:57 | |
| but it's not clear if the complexity is worth it. | 08:58 | ||
|
09:12
rurban_ joined
|
|||
| JimmyZ | nwc10: the reason I want 64bit for small int is that I can throw from unbox_i if there is a bigint flag | 09:29 | |
|
09:48
lizmat joined
|
|||
| timotimo | right, then you wouldn't have to check if the bigint contained is actually small enough for a 64bit register | 10:16 | |
|
10:17
Ven joined
11:38
FROGGS_ joined
11:51
brrt joined
|
|||
| brrt | good * | 12:00 | |
| JimmyZ | \o brrt | 12:03 | |
|
12:08
Ven joined
12:12
Ven joined
12:26
ShimmerFairy joined
|
|||
| jnthn | If you have 63 bits for little big ints you still have the "doesn't answer for free if it's going to fit in a 64-bit register" problem and so have probably only made things more complex than they are today for no real simplification. | 13:19 | |
|
13:21
brrt joined
|
|||
| ShimmerFairy | I'd rather just count limbs for bigint-too-big checking, assuming limbs are evenly divisible by small ints (or vice versa) :) | 13:22 | |
| jnthn | ShimmerFairy: You have to check if it's a little big int anyway before yo can safely ask how many limbs :) | 13:23 | |
| ShimmerFairy: So you get the fast-path for 32-bit things for free | |||
| JimmyZ | m: use nqp; say(unbox_i(-1e35)); | 13:25 | |
| camelia | rakudo-moar edffe0: OUTPUT«===SORRY!=== Error while compiling /tmp/suGhG7xCrNUndeclared routine: unbox_i used at line 1» | ||
| ShimmerFairy | jnthn: I suspect we can assume everything's in multiples of 8 bits though, right? :) (that is, no weird situation like 32-bit limbs and 36-bit native ints) | ||
| JimmyZ | m: use nqp; say(nqp::unbox_i(-1e35)); | ||
| camelia | rakudo-moar edffe0: OUTPUT«This type cannot unbox to a native integer in block <unit> at /tmp/spGkYfveXs:1» | ||
| jnthn | ShimmerFairy: I can't promise you much about the limbs :) | ||
| JimmyZ: That's a Num, so it certainly can't unbox as a native int :) | 13:26 | ||
| ShimmerFairy: I think it may be something odd like 28 bits or so | |||
| ShimmerFairy: You'll have to look at the libtommath code for answers, I suspect | |||
| ShimmerFairy | If there's a chance you can have 4-bit limbs and 5-bit native ints (for illustration, I'd hate that computer if real), then you'd have to be sure to check the "maybe limb" (the limb that can fit in a native up to a point) and check if it goes over its limit | 13:27 | |
| JimmyZ | m: use nqp; say nqp::unbox_i(-1e35) | ||
| camelia | rakudo-moar edffe0: OUTPUT«This type cannot unbox to a native integer in block <unit> at /tmp/H8tgw7B6de:1» | ||
| ShimmerFairy | m: use nqp; say nqp::unbox_i(-1e35.Int) | ||
| camelia | rakudo-moar edffe0: OUTPUT«0» | ||
| JimmyZ | hmm ,what is GLR one | ||
| jnthn | ShimmerFairy: Well, the robust way is just to keep mp_ints around for the positive and negative limit and compare | 13:28 | |
| ShimmerFairy: Which is what I'd probably do, and leave profiling to tell us if that's really not fast enough | |||
| ShimmerFairy | jnthn: I admittedly don't know what libtommath provides, so I could only think up the generalized solution :) | ||
| ("generalized" as in "library-agnostic", in this case) | 13:29 | ||
| I've only looked at gmp before concerning bigints, but never actually used it :P | 13:30 | ||
|
13:48
vendethiel joined
|
|||
| dalek | arVM: 4108c94 | FROGGS++ | src/6model/reprs/P6bigint.c: throw "cannot unbox" when bigint is too large |
13:50 | |
|
14:11
Util_ joined
14:20
JimmyZ joined
|
|||
| nwc10 | jnthn: yes, agree on complexity. I wrongly assumed that the reason for the question was about storing a larger range without hitting bigints. Not about simplifying unboxing in the common case. | 14:20 | |
|
14:31
brrt joined
14:37
tadzik joined
|
|||
| dalek | arVM/even-moar-jit: e3aa05c | brrt++ | src/jit/ (2 files): Add missing breaks and flag negation |
14:40 | |
|
16:27
brrt left
17:36
zakharyas joined
18:29
rurban_ joined
21:10
vendethiel joined
21:14
zakharyas joined
22:39
vendethiel joined
22:58
TEttinger joined
|
|||