Mike Gran <spk...@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
