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
