Re: Guile 64-bit Windows support, redux

[Jonas Hahnfeld]

On Tue, 2023-06-06 at 20:50 +0000, Mike Gran wrote:
> Hello Guile,

Hi Mike,

I'm sorry for "necrobumping" this thread; I wanted to reply back in
June but didn't have enough time to work through what I will explain
further below. In any case, I would very much like to see good Windows
64-bit support in Guile to make use of it in LilyPond.

> [...]
> 
> I'd be willing [1] to update the patches for MinGW support for
> review and inclusion into the main branch
> for 3.0.10 or 3.2 but, only if maintainers are open, in principle,
> to committing the most disruptive patch: the one where all
> long integers become intptr_t to deal with Window's stupid
> 4-byte longs on 64-bit OSs.  Without agreeing on that as a
> possibility, 64-bit Windows support is DOA.

For a long time, I wasn't really convinced by this argument until I
realized that the alternative would complicate cross-compilation and
move away from the simple {32-bit, 64-bit} x {little-endian, big-
endian} matrix for the bytecode.

> There are a couple of slightly outdated versions of janekke's 64-bit patch.
> Here, for example:
> 
> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=wip-mingw&id=76950b4281c7dfff78b9ead6d3d62c070bbc1f13

If I understand correctly, one of the contentious points of this commit
(apart from being big and having many changes in one) is that it moves
GMP away from long. IIRC there was a statement somewhere that GMP will
not change their APIs, which basically means that Guile on Windows
would forever be stuck with a quite significantly patched mini-gmp.

I would like to propose a different approach: It turns out to be
possible to just define scm_t_inum as intptr_t, while leaving GMP
interfaces alone (be that mini-gmp or a full GMP). Instead, the
mismatch in type widths can be handled during the conversion to mpz.
For a practical implementation, see the fourth patch attached to this
message.

Afterwards, the fifth patch takes care of the hashes, which are
expected to have the same width as pointers. This is required because
(at least) hashes of symbols are stored into the bytecode. Taken
together, this seems to enable enough functionality to run LilyPond
with Guile 3 on Windows.

What do you and others think of this approach, would this be "more"
acceptable to land in main?

Jonas

0001-scm_i_divide2double-Refactor-to-use-scm_to_mpz.patch
Description: Text Data

0002-scm_integer_modulo_expt_nnn-Refactor-to-use-scm_to_m.patch
Description: Text Data

0003-Rename-functions-that-should-accept-scm_t_inum.patch
Description: Text Data

0004-Decouple-scm_t_inum-from-long-datatype.patch
Description: Text Data

0005-Store-hashes-as-uintptr_t.patch
Description: Text Data

signature.asc
Description: This is a digitally signed message part