wide-integer

wide-integer copied to clipboard

Improve support for GCC's __int128.

• Implement construction-from/cast-to signed and unsigned versions of __int128.
• Separate as well as possible use of 128-bit in wide-integer versus 128-bit conversions.

See also some motivation for this issue in #133.

I tried adding that 'simple' constructor for 128-bit integers. And of course it's far more complex a change that I anticipated. Much supporting code in the file would need to be changed to accept __int128 unconditionally as a parameter.

It's worth considering two options:

1. proceed and support __int128 for libstdc++ in conformant mode (-std=c++XX, rather than -std=gnu++XX) with replacements for is_integral, is_signed, is_unsigned and digits, or
2. go with whatever the toolchain is doing, i.e. when using libstdc++, and -std=c++XX don't support __int128.

What's a good choice for on library is probably a good choice for both. What do you think?

I tried adding that 'simple' constructor for 128-bit integers. And of course it's far more complex a change that I anticipated. Much supporting code in the file would need to be changed to accept __int128 unconditionally as a parameter.

That's a hard one. Maybe we/I jumped in unprepared. Initially, I had tried to purposely disregard __int128, secretly hoping the problems therewith would go away. But this was naive.

Maybe we need to figure out which constructors/functions are needed.

Regardless of when/how __int128 is detected, what do we really need anyway`?

• Construction-from signed/unsigned __int128.
• Explicit cast-to signed/unsigned __int128.
• Global(ly found via ADL) binary operations add/sub/mul/div/logic, etc. signed/unsigned __int128 left-hand/right-hand with uinteide_t.
• Others?

I can look into Boost and see which functions we have. There is purposeful support for interaction of cpp_int with __int128 and there should b elots of clues there.

That's a fairly good list. There may be more but those are major needs. However, what support is provided is a choice made after the decision to support __int128 at all. There is very little to do if we choose (2) because then __int128 is just another integer type, little different from int. In fact it's just an edge case which is causing problems right now: for the libstdc++ / -std=c++XX combo, CNL expects __int128 and wide-integer doesn't deliver it.

There is very little to do if we choose (2) because then __int128 is just another integer type, little different from int

OK, well we could decide this at this point.

• Do support signed/unsigned versions of __int128 and base preliminary support on 2 above when present in toolchain.

OK, then I need to make the changes to CNL. They will mostly be removal of code to support __int128 so it will be a pleasure!

Note, however, that in the mode where __int128 isn't supported, there may be some weird incompatibilities or even ABI issues: if different TUs are compiled in different modes, who knows what might happen at link-time. However, this is presumably already an issue for users of __int128.

This work, whenever it continues, will also address some issues related to #229

Support is working for 64-bit limb. No community complaints.