On Wed, 2024-02-07 at 21:29 +0100, Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library wrote: > On Wed, 2024-02-07 at 15:23 -0500, Thompson, David wrote: > > On Wed, Feb 7, 2024 at 3:19 PM Jonas Hahnfeld <hah...@hahnjo.de> wrote: > > > > > > On Wed, 2024-02-07 at 09:19 -0500, Thompson, David wrote: > > > > On Thu, Jan 4, 2024 at 5:40 AM Jonas Hahnfeld wrote: > > > > > > > > > > On Tue, 2023-11-28 at 22:04 +0100, Jonas Hahnfeld wrote: > > > > > > > > > > > > Ping, any comments on this approach? I built binaries for LilyPond > > > > > > 2.25.10 using these patches applied on top of Guile 3.0.9 and the > > > > > > result seems to work fine on Windows. > > > > > > > > > > Another ping; meanwhile we switched to building the official binaries > > > > > of LilyPond with Guile 3.0 starting from version 2.25.11, but it would > > > > > be really great to get rid of our downstream patches... > > > > > > > > Just chiming in to say this is a very exciting development that I had > > > > missed when the patch set was first sent! > > > > > > > > Does this allow a fully featured Guile build or are some things still > > > > disabled? Does JIT work? > > > > > > It's functional enough to run LilyPond (which uses quite a bit of > > > Guile) and well enough so that there is only one complaint (that I know > > > of so far) about multiplication with negative numbers not working > > > right. If I remember correctly from quickly having a look, that's > > > related to scm_integer_mul_ii using long_magnitude which doesn't quite > > > work on Windows 64-bit. For LilyPond, we disable some features (JIT, > > > threading, networking; you can look at the full build recipe here: > > > https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L628 > > > ) and I don't know which of these would work or how much it would take > > > to support them. > > > > Ah, bummer. That's a lot of disabled features. JIT and threads are > > must-haves for my use-cases. I guess I'll continue waiting for > > someone to figure out how to build a fully featured Guile on Windows. > > Any takers? ;) > > Isn't the common wisdom that you should learn to crawl and walk before > starting to run? 😉 first we need a booting and working base of Guile > before the rest can follow at some point. For LilyPond's binaries, we > disable networking and threads on all platforms so these may just work. > Regarding the JIT, I think I disabled it right away when I started > trying to understand what the issues were, so it's possible that the > state is not actually that dire...
So I can confirm that JIT indeed doesn't work right now on 64-bit MinGW, but it's relatively easy to fix (first patch). In essence lightening was getting the calling convention wrong. Compilation just works --with-threads, as long as bdwgc was built with --enable-threads=posix to override the automatic detection of win32 threading. I haven't tested if it actually works, but there might be a good chance. For the one known issue I mentioned above, the fix is also not too difficult, just being a bit more careful with mixing scm_t_inum and long (see second patch). I'm also explicitly CC'ing Andy and Ludo - we really need a statement by a maintainer whether this can land. From my point of view, it's a clear improvement in terms of supported platforms, plus tested by LilyPond since some time now which is probably one of the bigger "customers". Jonas
From e701b1583052102a5e1758394e4c3a1fb7565d27 Mon Sep 17 00:00:00 2001 From: Jonas Hahnfeld <hah...@hahnjo.de> Date: Wed, 20 Mar 2024 20:26:36 +0100 Subject: [PATCH 1/2] Fix lightening x86_64 Windows calling convention * libguile/lightening/lightening/x86.c: * libguile/lightening/lightening/x86.h: Check _WIN64 macro as set for mingw64. --- libguile/lightening/lightening/x86.c | 10 +++++----- libguile/lightening/lightening/x86.h | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/libguile/lightening/lightening/x86.c b/libguile/lightening/lightening/x86.c index f8ac4b0b8..6963d90fd 100644 --- a/libguile/lightening/lightening/x86.c +++ b/libguile/lightening/lightening/x86.c @@ -237,7 +237,7 @@ jit_init(jit_state_t *_jit) static const jit_gpr_t abi_gpr_args[] = { #if __X32 /* No GPRs in args. */ -#elif __CYGWIN__ +#elif defined(__CYGWIN__) || defined(_WIN64) _RCX, _RDX, _R8, _R9 #else _RDI, _RSI, _RDX, _RCX, _R8, _R9 @@ -247,7 +247,7 @@ static const jit_gpr_t abi_gpr_args[] = { static const jit_fpr_t abi_fpr_args[] = { #if __X32 /* No FPRs in args. */ -#elif __CYGWIN__ +#elif defined(__CYGWIN__) || defined(_WIN64) _XMM0, _XMM1, _XMM2, _XMM3 #else _XMM0, _XMM1, _XMM2, _XMM3, _XMM4, _XMM5, _XMM6, _XMM7 @@ -317,7 +317,7 @@ reset_abi_arg_iterator(struct abi_arg_iterator *iter, size_t argc, memset(iter, 0, sizeof *iter); iter->argc = argc; iter->args = args; -#if __CYGWIN__ && __X64 +#if (defined(__CYGWIN__) || defined(_WIN64)) && __X64 // Reserve slots on the stack for 4 register parameters (8 bytes each). iter->stack_size = 32; #endif @@ -330,12 +330,12 @@ next_abi_arg(struct abi_arg_iterator *iter, jit_operand_t *arg) enum jit_operand_abi abi = iter->args[iter->arg_idx].abi; if (is_gpr_arg(abi) && iter->gpr_idx < abi_gpr_arg_count) { *arg = jit_operand_gpr (abi, abi_gpr_args[iter->gpr_idx++]); -#ifdef __CYGWIN__ +#if defined(__CYGWIN__) || defined(_WIN64) iter->fpr_idx++; #endif } else if (is_fpr_arg(abi) && iter->fpr_idx < abi_fpr_arg_count) { *arg = jit_operand_fpr (abi, abi_fpr_args[iter->fpr_idx++]); -#ifdef __CYGWIN__ +#if defined(__CYGWIN__) || defined(_WIN64) iter->gpr_idx++; #endif } else { diff --git a/libguile/lightening/lightening/x86.h b/libguile/lightening/lightening/x86.h index 983ebdb8f..7da8c5977 100644 --- a/libguile/lightening/lightening/x86.h +++ b/libguile/lightening/lightening/x86.h @@ -92,7 +92,7 @@ # define JIT_F6 _XMM6 # define JIT_FTMP _XMM7 # define JIT_PLATFORM_CALLEE_SAVE_GPRS JIT_TMP0 -#elif __CYGWIN__ +#elif defined(__CYGWIN__) || defined(_WIN64) # define JIT_R0 _RAX # define JIT_R1 _RCX # define JIT_R2 _RDX -- 2.44.0
From cf380c1a734acd0d22041c7c875fbffc6b535d2a Mon Sep 17 00:00:00 2001 From: Jonas Hahnfeld <hah...@hahnjo.de> Date: Wed, 20 Mar 2024 20:57:02 +0100 Subject: [PATCH 2/2] Use inum_magnitude for inums * libguile/integers.c: Call inum_magnitude instead of long_magnitude for scm_t_inum arguments. --- libguile/integers.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/libguile/integers.c b/libguile/integers.c index 23bd2c0d5..380ff193c 100644 --- a/libguile/integers.c +++ b/libguile/integers.c @@ -251,7 +251,7 @@ inum_to_bignum (scm_t_inum i) if (i > 0) return ulong_to_bignum (i); - return i == 0 ? make_bignum_0 () : make_bignum_1 (1, long_magnitude (i)); + return i == 0 ? make_bignum_0 () : make_bignum_1 (1, inum_magnitude (i)); #else return make_bignum_from_int64 (i); #endif @@ -3061,15 +3061,15 @@ scm_integer_mul_ii (scm_t_inum x, scm_t_inum y) return SCM_I_MAKINUM (k); #endif - mp_limb_t xd[1] = { long_magnitude (x) }; + mp_limb_t xd[1] = { inum_magnitude (x) }; mp_limb_t lo; int negative = (x < 0) != (y < 0); - mp_limb_t hi = mpn_mul_1 (&lo, xd, 1, long_magnitude (y)); + mp_limb_t hi = mpn_mul_1 (&lo, xd, 1, inum_magnitude (y)); if (!hi) { if (negative) { - if (lo <= long_magnitude (SCM_MOST_NEGATIVE_FIXNUM)) + if (lo <= inum_magnitude (SCM_MOST_NEGATIVE_FIXNUM)) return SCM_I_MAKINUM (negative_long (lo)); } else if (lo <= SCM_MOST_POSITIVE_FIXNUM) @@ -3100,7 +3100,7 @@ scm_integer_mul_zi (struct scm_bignum *x, scm_t_inum y) struct scm_bignum *result = allocate_bignum (xn + 1); mp_limb_t *rd = bignum_limbs (result); const mp_limb_t *xd = bignum_limbs (x); - mp_limb_t yd = long_magnitude (y); + mp_limb_t yd = inum_magnitude (y); int negate = bignum_is_negative (x) != (y < 0); mp_limb_t hi = mpn_mul_1 (rd, xd, xn, yd); if (hi) -- 2.44.0
signature.asc
Description: This is a digitally signed message part