On Fri, Jan 22, 2010 at 1:16 AM, Cactus <[email protected]> wrote: > Case Vanhorsen and I have been exchanging private emails on the issues > caused by the long type on Winndows being 32-bits even on x64 > systems. It turns out that this is related to future GMP > compatibility. > > Once MPIR 1.3 is released, I think we need to decide on a strategy for > future GMP compatibility and for handling the conversion of signed and > unsigned integers of various lengths to and from mpz types. > > GMP 5 introduces a new mp_bitcnt_t that is used where bit counts are > needed. It notes that this type is now typed as unsigned long but that > it could be unsigned long long. By introducing this type and setting > it as a an appropriate basic type that is 32-bits on 32-bit systems > and 64-bits on 64-bit systems, we can, once the code works, > _partially_ solve the Windows ABI issue as well as moving towards GMP > compatibility.
I think we should definately do this. The current version of gmpy has several limitations on 64-bit Windows caused by 32 vs. 64 bit longs. > > The other issue on GMP/MPIR compatibility is that some of the new > function namings are different. We can either simply change our names > to the GMP ones or have a set of compatibility defines added in GMP > compatibility mode. I would prefer a consistent set of names without requiring installation with GMP compatibility mode. gmpy can use either GMP or MPIR and I usually have both versions installed and compile/test with both versions. I can always add my own defines to mask the differences so I'd be okay if you used compatibility defines in GMP mode. But I would be concerned that API will slowly drift apart. > > Last but not least we have the issue of whether to do anything about > all the functions that move things between signed and unsigned ints > and mpz types. Ideally we would have two types defined as 'MPIR > signed and unsigned integers' at top level and all the 'ui' and 'si' > functions would use these inetegrs and would work whatever their > lengths are in relation to the length of the mp_limb_t type. But this > would involve quite a bit of work. What about adding 'ulli' and 'slli' variants for all the functions that move between int and mpz types? Just looking at mpz_set_ui and mpz_add_ui, it looks like required changes would be very minor as long as BITS_PER_ULLONG <= 2*GMP_NUMB_BITS. This is true on 64-bit Windows as long as nails are not used. I'm not sure if there are systems where the above does not hold when nails are not used. > > In my view GMP compatibility is important so I would like to see, (1) > MPIR add the mp_bitcnt_t, and (2) get this to work when it is both a > 32 and a 64 bit type. > > Personally I would also like to see new GMP and MPIR functions named > in the same way but this would depend ona level of co-oparation > between the GMP and MPIR communities that seems unlikely to occur. > But I think we need to address this. > > This would then leave us with the issue of functions that involve mpz > types and signed/unsigned integers. This is a lot harder as it may > involve quite a bit of work. Even though I primarily develop on Linux, I'll help out on this. Case > > I would like to hear other people's views on these issues. > > Brian > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
