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.
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
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
MasterDuke woohoo, all nqp tests pass 10:49
now to try rakudo
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
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++

Powered by Cro and the Raku® Programming Language.

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

Thank you!