|
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
|
|||