From: Mark H Weaver <mhw@netris.org>
To: Mike Gran <spk121@yahoo.com>
Cc: Christoph Buck <christoph.buck@smartoptics.de>, guile-devel@gnu.org
Subject: Re: Compiling guile-2.2.4 for mingw
Date: Tue, 20 Nov 2018 15:27:53 -0500 [thread overview]
Message-ID: <87pnuzv6hn.fsf@netris.org> (raw)
In-Reply-To: <20181120174505.GA23955@joshua.dnsalias.com> (Mike Gran's message of "Tue, 20 Nov 2018 09:45:05 -0800")
Mike Gran <spk121@yahoo.com> writes:
> On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
>> Is there currently no way to get guile running under mingw-64bit? My plan
>> was to integrate guile in a project of mine which currently only builds
>> under 64bit.
>
> Well anything is possible, of course. Here is a list of my recollections,
> but it has been a few months since I looked at it.
>
> First, as Eli Z mentions in his email, GMP may need to be fixed to not
> make incorrect assumptions about the sizeof(long) and int, etc.
bytevector-u64-{ref,set!} use 'mpz_import' and 'mpz_export', but I don't
see any assumption in that particular code that 'long' is 64-bits.
However, in general, it does seem to be the case that Guile code has
often been written with the assumption that sizeof(long) ==
sizeof(void*). I fixed several of these instances, but I suspect that
many more remain. That issue is being tracked here:
https://bugs.gnu.org/22406
> Second, the Guile numbers infrastructure should probably be rejiggered
> to keep using 32-bit INum immediate number types even under 64-bit
> builds if long == 32-bit, or to always use int64_t instead of int.
No need for rejiggering, because it's already the case. Guile currently
always uses 'long' as the immediate number type, precisely because
that's the C integer type that GMP's mpz_*_si functions accept.
Specifically, numbers.h contains this:
typedef long scm_t_inum;
#define SCM_I_FIXNUM_BIT (SCM_LONG_BIT - 2)
#define SCM_MOST_NEGATIVE_FIXNUM (-1L << (SCM_I_FIXNUM_BIT - 1))
#define SCM_MOST_POSITIVE_FIXNUM (- (SCM_MOST_NEGATIVE_FIXNUM + 1))
> Third, there are a few of the Guile Virtual Machine opcodes that need
> to disambiguate if it means sizeof(void *) or size of an integer type.
I'm not sure I understand. Can you give a specific example of an opcode
that needs to be disambiguated?
> I think it might be a tricky business overall.
>
> I only fixed that MinGW build enough to enter a game jam with Guile,
> so I haven't put too much effort into it, really. But I came in
> 10th place, so hooray.
Nice! :)
Thanks,
Mark
next prev parent reply other threads:[~2018-11-20 20:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 14:31 Compiling guile-2.2.4 for mingw Christoph Buck
2018-11-20 15:39 ` tomas
2018-11-20 15:59 ` Mike Gran
2018-11-20 17:16 ` Christoph Buck
2018-11-20 17:45 ` Mike Gran
2018-11-20 20:27 ` Mark H Weaver [this message]
2018-11-20 17:10 ` Eli Zaretskii
2018-11-20 17:53 ` Jan Nieuwenhuizen
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=87pnuzv6hn.fsf@netris.org \
--to=mhw@netris.org \
--cc=christoph.buck@smartoptics.de \
--cc=guile-devel@gnu.org \
--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).