marc.glisse at inria.fr
Sun Jul 29 22:29:58 CEST 2012
last conversation about 'long long' was in March, here is a link to one of
2 possibilities were discussed:
1) make the _ui functions take a mp_limb_t instead of an unsigned long (or
maybe the longest of the two). This provides long long support on those
platforms that can most benefit from it without complicating the interface
or the code (it would actually simplify the code a bit).
2) provide additional functions for long long, with a configure test to
disable this code on platforms that do not have long long (are there many
of those?). In the worst case we could document a macro GMP_USE_LONG_LONG
to let users decide.
The alimb branch (any progress?) decouples limbs from builtin types. With
some extra effort, that might make it possible to compile a file
mpz/*_ui.c twice with different macros to generate both the usual _ui
function and a new _ul (or _ull?) function for long long. It will then be
trivial to add _u128 versions for unsigned __int128 if we decide to. This
approach may cause a bit of binary code duplication in the library though.
Does this match your vision of the current status? Any opinion on the best
way forward? Or a veto against long long?
More information about the gmp-devel