Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:05 reportable6 joined 00:42 ggoebel_ joined 00:45 dogbert17 left, dogbert17 joined 00:46 dogbert17 left, dogbert17 joined 06:02 reportable6 left 06:05 reportable6 joined 06:54 brrt joined 07:13 ilogger2 left, ilogger2 joined
Nicholas good *, #moarvm 07:23
MasterDuke hey hey. anybody know how to force windows/msvc to use 64-bit longs? 08:01
moon-child #define long long long 08:03
MasterDuke heh. without editing source or project files? 08:04
moon-child not afaik. long is 32-bit under the windows abi, so changing it categorically that way would make any use of system libraries break 08:05
why do you want to do that?
brrt ohai #moarvm
MasterDuke: context would be appreciated :-) 08:06
MasterDuke my gmp branch of moarvm builds fine on windows with msvc. so does nqp. but nqp fails some tests because values which fit in a long on linux no longer do on windows 08:07
brrt I see.
moon-child sounds like a bug in gmp, tbh
brrt but this means that there's somewhere where either MoarVM or libgmp is using 'long' where it should be using MVMint64 or int64_t
MasterDuke so this is a problem github.com/MasterDuke17/MoarVM/blo...t.c#L9-L14 08:08
m: use nqp; my int $a = nqp::unbox_i(nqp::fromstr_I("9223372036854775807", Int)); say $a # so this throws 08:09
camelia 9223372036854775807
MasterDuke my thought for how to get around it in code is just read the limbs from the bigint manually, e.g., something like `if (mpz_sizeinbase(*a, 2) <= 1) { return (MVMint64) (mpz_getlimbn(*a, 0) + mpz_getlimbn(*a, 1)) } else { ... }` 08:13
moon-child how about a patch to gmp? Seems simpler
MasterDuke wrapped in a `#ifdef _MSC_VER` 08:14
i don't want to have to carry a gmp patch, and they have some crazy code 08:15
moon-child fair enough
MasterDuke when building GMP with regular ./configure, you can give it an `ABI=(32|64)` option, but i don't know exactly what that does, or how to try it out when building a visual studio project 08:17
timo you may have to / want to find IS_BIG for this?
could be the "store small bigints in half a pointer" optimization
how did we end up handling gmp's signal-happyness? 08:18
MasterDuke github.com/MasterDuke17/MoarVM/blo....c#L38-L42 and github.com/MasterDuke17/MoarVM/blo...#L371-L388
yeah, there will likely have to be a bunch more places where i special case msvc if i can't figure out how to get it to use 64-bit longs 08:19
timo signal handlers are per-process, not per thread, aren't they? 08:20
MasterDuke i am using the 'x64' instead of the 'Win32' build target in the project file
i think so 08:21
timo ;_;
so this pretty explicitly races
signal man page says use sigaction instead 08:22
MasterDuke stackoverflow.com/questions/246433...l-handlers seems to show a possible solution 08:23
so the current code might/will likely be a source of bugs in threaded code that does big integer exponentiation, but first i'm going to worry about getting nqp tests to pass 08:25
timo yeah if you think "man, exponenting this huge array of integers is so slow, i'll just hyper it" then bam
MasterDuke ugh docs.microsoft.com/en-us/cpp/build...w=msvc-160 doesn't have a here's-how-to-force-long-to-be-64bit tip 08:55
Nicholas You can't usefully force any type to be a different type because you utterly bugger every ABI (eg your ability to call into the whole C library) 09:05
I'm wonderin if the solution is (rougly) 09:06
that if test with `mpz_fits_slong_p`
and then code that checks wehther sizeof(long) < sizeof(MMVInt64)
and in that
do it in two halves 09:07
get the bottom 32 bits withmpz_get_ui
do bigint maths to divide by the constnat 2**32 (or does it have a right shift funciton)
I assume that a right shift is cheap
then try to see if what remains in your temp value *does* fit a 32 bit logn
MasterDuke well, i have confirmed that `mpz_getlimbn(*a, 0) + mpz_getlimbn(*a, 1)` does give the correct value 09:08
Nicholas and if so, get it, upshift it by 32 bit, and or the two parts together in C
are limbs defined to be the same size as long?
MasterDuke don't remember, but i think so 09:09
09:10 patrickb joined
MasterDuke hm, nope. `./nqp-m.exe : Cannot unbox 63 bit wide bigint into native integer, limb 0 == 9223372036854775805` 09:13
where i jsut used `%llu` and `mpz_getlimbn(*a, 0)` 09:14
Nicholas mpz_sizeinbase(value, 16) might be a fast way to figure out if it fits into 64 bits
or actually 8, as I think because of signs it needs to fit into 63 bits
(Although -2**63 would then be a special case)
MasterDuke i think mpz_size (a) < 2 would be the fastest initial test, since that's just the number of limbs 09:17
ok, now t/serialization/01-basic.t is passing, just have two failing tests in t\nqp/060-bigint.t and eleven in t\hll/06-sprintf.t 09:49
arg, one of the fails is from nqp::div_In 09:56
that's scary code
so the test is `my $huge := nqp::pow_I(box(10), box(300), $n_type, $bi_type); nqp::iseq_n(nqp::div_In(box(1), $huge), 1e-300);` 09:58
on windows i'm getting 1.4932228741754776e-300 isntead 09:59
turns out to have been an easy fix. now just the sprintf fails 10:08
10:44 feb left
MasterDuke woohoo, all nqp tests pass 10:49
now to try rakudo
10:52 brrt left
MasterDuke arg. and of course my nqp was too old, and when i try to rebuild it i get the complaint about not finding gmp.h when compiling the runner. don't remember how i fixed that last time... 11:54
oh, another easy fix 11:57
12:02 reportable6 left 12:05 reportable6 joined
MasterDuke rakudo installs 12:05
couple fails in `nmake m-test` 12:08
patrickb MasterDuke: Are you working on gmp on Windows? 12:19
MasterDuke yeah
patrickb Which route did you go wrt build system? 12:21
The above reads like you've come a long way already.
MasterDuke well, i'm just working on/with msvc right now
so using msbuild to build the project file that the SMP fork adds to gmp 12:22
i haven't tried wingw yet
*mingw
patrickb Using msbuild seems sane. On MinGW it might just work with the linux toolchain. 12:23
MasterDuke++
13:15 ggoebel_ left, ggoebel_ joined 13:17 ggoebel_ left, ggoebel_ joined 13:18 brrt joined 13:49 brrt left 14:12 frost left 15:06 ilogger2 left, ilogger2 joined 15:53 patrickb left 16:00 ggoebel joined 16:03 ggoebel_ left 16:09 lizmat left 16:10 LizBot left 16:23 lizmat joined 16:26 LizBot joined 17:08 ggoebel left 18:02 reportable6 left 18:03 ggoebel joined, reportable6 joined 20:18 hankache joined 20:58 hankache left 21:15 ggoebel left 21:50 linkable6 left 21:53 linkable6 joined 23:39 benchable6 left, releasable6 left, bisectable6 left, shareable6 left, statisfiable6 left, committable6 left, unicodable6 left, greppable6 left, reportable6 left, evalable6 left, linkable6 left, notable6 left, coverable6 left, nativecallable6 left, bloatable6 left, squashable6 left, sourceable6 left, quotable6 left, tellable6 left, unicodable6 joined, statisfiable6 joined, greppable6 joined, bloatable6 joined 23:40 releasable6 joined, benchable6 joined, notable6 joined, nativecallable6 joined, squashable6 joined, evalable6 joined 23:41 committable6 joined, sourceable6 joined, bisectable6 joined, shareable6 joined, linkable6 joined 23:42 quotable6 joined, tellable6 joined