On 23/01/2018 21:20, 'Bill Hart' via mpir-devel wrote: > > > On 23 January 2018 at 22:13, Brian Gladman <b...@gladman.plus.com > <mailto:b...@gladman.plus.com>> wrote: > > On 23/01/2018 20:00, 'Bill Hart' via mpir-devel wrote: > > Hi Brian, > > > > I believe the problem is that our LLL code actually relies on a 64 bit > > exponent on Windows 64 (in practice, not just in theory), but GMP (or > > the compatibility function) only returns a 32 bit one. > > Ah, OK. So basically FLINT won't work on Windows x64 because longs are > 32-bits and FLINT expects longs to be 64-bits. > > So FLINT on Windows x64 won't work at all with current versions of GMP > since longs are 32-bits. And it won't work with MPIR 3 because we have a > function that uses 32 bit longs in its interface. > > But could we not have a 'compatibility define' in MPIR that makes the > function work for 64-bit longs when needed? > > I guess that's an option. It won't fix the GMP issue for us either way.
I was pondering this issue further last night and it occurred to me that there is a solution that I wish I had thought of earlier. The introduction of the typedefs mpir_ui and mpir_si for unsigned and signed integers in the MPIR API was an almost complete solution to the Windows x64 problem caused by its use of 32-bit integers. It worked almost everywhere as a result of automatic promotion rules except for just two functions that returned integers via pointers: double mpz_get_d_2exp(mpir_si *exp2, mpz_srcptr src) double mpf_get_d_2exp(mpir_si *exp2, mpf_srcptr src) These caused a number of bugs since 64-bit values would be written into 32-bit ones corrupting adjoining memory and 32-bit values would be written to 64-bit ones leaving 32-bits undefined. What has just occurred to me is that we can arrive at a 'perfect' MPIR integer API by reversing how the doubles and integers are returned: mpir_si mpz_get_2exp_d(double *r, mpz_srcptr src) mpir_si mpf_get_2exp_d(double *r, mpz_srcptr src) By introducing these two functions we will have no more 32/64-bit trouble on Windows x64 provided these new functions are used in place of the old ones. And, if the FLINT code is a typical example, the work needed to switch to these new functions will be small at least at the code level. This still leaves the problem in GMP but FLINT has a GMP compatibility layer where these two new functions could be derived from their GMP equivalents or implemented directly. As the MPIR Windows developer/maintainer, moving to an MPIR API that is pure in respect of integer length is compelling, especially so as it is not hard to achieve at the code level. But it would seem that making this change won't be possible unless we can find a volunteer to do the work that this requires for Linux/Unix and for delivering new MPIR distributions. Leaving FLINT on Windows x64 (and other applications that depend on it) reliant on old versions of MPIR and GMP would effectively mean that it would progressively die on Windows since it would not be able to take advantage of the work that Jens Nurmann and I have done in adding assembler code support for recent Intel processor architectures. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
