From: Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org>
To: Mike Gran <spk121@yahoo.com>,
"guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: Re: Guile 64-bit Windows support, redux
Date: Tue, 28 Nov 2023 22:04:03 +0100 [thread overview]
Message-ID: <3f3c0be57479e0566ada30b0a012d9d6876281d5.camel@hahnjo.de> (raw)
In-Reply-To: <d01573989a3bc47de593b53afb04f41a4653a479.camel@hahnjo.de>
[-- Attachment #1: Type: text/plain, Size: 2695 bytes --]
On Sun, 2023-10-29 at 22:34 +0100, Jonas Hahnfeld wrote:
> 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?
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.
> Jonas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-11-28 21:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1629803116.370682.1686084646758.ref@mail.yahoo.com>
2023-06-06 20:50 ` Guile 64-bit Windows support, redux Mike Gran
2023-06-06 20:56 ` Jean Abou Samra
2023-06-06 21:10 ` [EXT] " Thompson, David
2023-06-06 21:58 ` Mike Gran
2023-06-08 19:50 ` Maxime Devos
2023-06-08 20:46 ` Mike Gran
2023-06-09 11:01 ` Maxime Devos
2023-06-22 13:36 ` Mike Gran
2023-10-29 21:34 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2023-11-28 21:04 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library [this message]
2023-11-28 22:04 ` Dr. Arne Babenhauserheide
2024-01-04 10:40 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2024-02-06 6:44 ` Dr. Arne Babenhauserheide
2024-02-07 14:19 ` Thompson, David
2024-02-07 20:19 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2024-02-07 20:23 ` Thompson, David
2024-02-07 20:29 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2024-03-20 20:28 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2024-03-20 20:40 ` Thompson, David
2024-03-23 15:09 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2024-03-29 17:20 ` Thompson, David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f3c0be57479e0566ada30b0a012d9d6876281d5.camel@hahnjo.de \
--to=guile-devel@gnu.org \
--cc=hahnjo@hahnjo.de \
--cc=spk121@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).