gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] win64


From: Camm Maguire
Subject: Re: [Gcl-devel] win64
Date: Mon, 01 Dec 2014 11:18:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Greetings, and thanks so much for your feedback!

Below I discuss the integer issues a little.  There seems to be another
obstacle -- does win64 require some special mprotect like call to make
data memory executable?  The standard calls used in the 32bit port are
leading to a segfault whenever the instruction pointer enters a loaded
module.   Perhaps an instruction cache clearing call is required, unlike
the x86 counterpart?

Gabriel Dos Reis <address@hidden> writes:

> On Sun, Nov 30, 2014 at 5:45 AM, Camm Maguire <address@hidden> wrote:
>
>     Greetings!  If we are going to use mingw64, with a 32bit long, is there
>     any objection to having a 32bit fixnum?
>
> some comments:
>
>   (1) the gcc driver on mingw64 is actually a cross-compiler (works very 
> well) capable of generating 32-bit and 64-bit codes. 
>   (2) intptr_t is currently 64-bit on mingw64.  Would it make sense to have 
> more than 32-bit fixnum?
>   (3) mingw64 has large file capability; I was under the impression that 
> would force a 64-bit fixnum.  Is that true?
>
> Windows 64-bit (the default these days) is an LLP64 platform; I would be go 
> for the sized integer types notation to avoid surprises when
> porting....
>  

Sound advice, as always.

In general, it would appear there is little point to win64 with 32bit
fixnums but for some sort of 'support'.  There are three common
conversions that need efficiency:

1) object (pointer) to/from int.  This is essentially intptr_t as
previously recommended.

2) fixnum (i.e. unboxed integer) arithmetic, especially when compiled,
and subsidiary to this, immediate fixnum arithmentic (i.e. the location
and size of the unallocated tagged object fixnum table).

3) conversions into and out of gmp.  We make moderate use of the _ui gmp
functions, and heavier use in master.  On all other platforms, a fixnum
is of the same size as an unsigned long, and one typeing operation alone
suffices to determine the interface into gmp.  If we make fixnum the
same size as long long (!=long), we will have to write special wrappers
for each of these functions to be installed on this port alone.  Truly
ugly, though might be cleverly accomplished with some cpp magic.

In short, just tying ourselves to stdint intptr_t does not address the
gmp problem, and will never do so until they export _uintptr_t
functions.  Thus we have to roll our own solution anyway.

It probably makes sense to bite the bullet and go for a 64bit fixnum,
though this will complicate GCL's internals significantly.

Take care,


>
>     Take care,
>    
>     Kilian Singer <address@hidden> writes:
>    
>     > Dear Camm,
>     > as far as I understand the msys mingw installation:
>     > You have msys64/usr/bin/gcc which behaves most unix like but
>     > for deployment it needs cygwin. So this gcc is best used to compile
>     > tools which you only use within the msys installation. The compiler is
>     > used as standard if the shell is run from:msys2_shell.bat
>     >
>     > Then you have msys64/mingw64/bin/gcc which is equal to
>     > x86_64-w64-mingw32-gcc and is made to compile windows64 bit
>     > such that you can get a single file without the need for dlls.
>     > So my guess was always that  msys64/mingw64/bin/gcc is the compiler to
>     > use for win64.
>     >
>     > Indeed the microsoft visual studio compiler has sizeof(long) 4 in
>     > both 32 and 64 bit.
>     >
>     > This is as much as I could find on the topic:
>     > http://stackoverflow.com/questions/7607502/sizeoflong-in-64-bit-c
>     >
>     > https://cygwin.com/cygwin-ug-net/programming.html
>     >
>     > I guess it would be safest to replace all long by long long in gmp and 
> gcl.
>     >
>     > And then compile with gcc in mingw64.
>     >
>     > Best regards
>     > Kilian
>     >
>     >
>     > Am 25.11.2014 um 17:48 schrieb Camm Maguire:
>     >> Greetings, and thank you again for making this machine available.
>     >>
>     >> I am confused at the diversity of abi's and do not know how to proceed.
>     >>
>     >> The c:/msys64/usr/bin/gcc has an 8 byte long, whereas
>     >> c:/msys64/mingw64/bin/gcc has 4 bytes, forcing gcl to work with 'long
>     >> long'.  The system gmp libraries also apparently have a 4 byte long, so
>     >> we need to either build our own or download a version with a 'long 
> long'
>     >> gmp limb.  I've attempted this, but gmp has a configure error in this
>     >> configuration, at least on first attempt.
>     >>
>     >> I don't see why we don't try to work with c:/msys64/usr/bin/gcc, except
>     >> for the fact that apparently external packages, like mingw gmp, have
>     >> been built with a 4 byte long, and because I really don't know what it
>     >> is :-).  Ultimately we need for this to work 'out of the box' with
>     >> whatever the 'standard user' will install.
>     >>
>     >> Is there a standard here?  If it is a four byte long, do you know if 
> gmp
>     >> can be built with a long long limb?  The documentation does not list
>     >> mingw explicitly among the possible targets in this regard.  Can we 
> work
>     >> rather with c:/msys64/usr/bin/gcc?
>     >>
>     >> Take care,
>     >>
>     >
>     >
>     >
>     >
>     >
>    
>     --
>     Camm Maguire                                        address@hidden
>     ==========================================================================
>     "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>    
>     _______________________________________________
>     Gcl-devel mailing list
>     address@hidden
>     https://lists.gnu.org/mailman/listinfo/gcl-devel
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]