|Bill Allombert on Thu, 02 Jul 2009 14:41:53 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Pari 64bit on Windows|
On Wed, Jul 01, 2009 at 11:10:16PM +0100, Jason Moxham wrote: > On Wednesday 01 July 2009 17:35:09 Bill Allombert wrote: > > On Wed, Jul 01, 2009 at 03:39:03PM +0100, Jason Moxham wrote: > > > Hi > > > > > > I've got Pari-svn running on Windows with/without GMP/MPIR in 64bit mode. > > > This is with MSVC , and when MinGW/MSYS goes 64bit it will work with that > > > :) The main problem with Windows64 is that it uses a LLP data model > > > rather than the usual LP data model , this means that long's are 32 bit. > > > I'm doing this > > > > Is there no way to tell the compiler to use the LP model nevertheless ? > > > > I'm afraid not , Microsoft has made the bed , and we have to lie in it :) I do not have to lie in it. Sorry to insist on that point. > If there was , it presumably would only work for a statically linked exe with > NO external dependences (even libc) Not really: we would be restricted to libc functions that does not use long arguments. But since we would have most of our data as 64bit, we would not be able to use libc functions that deal with 32bit long integers anyway. For example consider the function labs. This function takes a long integer and returns a long integer. If we were to apply your change to use paritemplong_t, this function would still take a long and not a paritemplong_t (a long long) so we would need to change labs to llabs. In the LP model, we would still be allowed to call llabs((long long) x) so it would still be far less trouble. The LLP model make much of the traditional C library useless for 64bit objects. Secondly, MS could provide a libc built for the LP model. Cheers, Bill.