Hi, I’m working on a C++ proposal which would standardize 128-bit integers:
https://eisenwave.github.io/cpp-proposals/int-least128.html
I would greatly appreciate any feedback on this. It would be especially helpful if you could double-check whether what I’ve written under “Impact on implementations” makes sense, or whether I’ve missed some major difficulties.
Stream of conscious review here as I read/scroll through this. Note I am knowledgeable about EWG, not Library (and also a Clang dev, when this probably wants to also/primarily target our libcxx folks) , so my suggestions might not be completely useful. But as the author of _BitInt and an EWG Chair, I thought my feedback might be useful anyway.
Audience: Need LEWG there. This probably is also going to need to visit EWG at one point, adding a type is typically a ‘core language’ thing. Stuff like promotions/etc need to be dealt with.
Author: include your email textually as well, some folks ‘print’ these for review, and losing that info would be painful for them.
3.1.3: Might want to cover ARM there as well in your bullet lists.
7.3: the lack of hardware support makes division of >128 REALLY difficult. It means we need to have runtime support for these, which was a giant Pain for _BitInt
7.4: The ‘no core language changes’ here I think is absurdly optimistic, and likely won’t survive to R3 
8.1.4: Note that in your chart, you may wish to split out C and C++ support. Clang supports _BitInt as an extension in C++, but GCC does not (due in part to them having separate frontends). So saying ‘GCC’ is perhaps confusing.
Thanks for your feedback; here are the changes:
Audience: Need LEWG there. This probably is also going to need to visit EWG at one point, adding a type is typically a ‘core language’ thing. Stuff like promotions/etc need to be dealt with.
Done.
Author: include your email textually as well, some folks ‘print’ these for review, and losing that info would be painful for them.
Done.
3.1.3: Might want to cover ARM there as well in your bullet lists.
I’ve added ARM and RISC-V and made it a table.
7.3: the lack of hardware support makes division of >128 REALLY difficult. It means we need to have runtime support for these, which was a giant Pain for
_BitInt
It sure is, but I don’t think that would be an issue for my proposal. _BitInt exists and so the infrastructure for doing multi-precision arithmetic already exists. And as the proposal points out, long long is basically big-int on 8-bit targets as well. Not sure how this was historically implemented though.
7.4: The ‘no core language changes’ here I think is absurdly optimistic, and likely won’t survive to R3
Well, it’s true for now at least. I don’t see obvious problems with extended integers yet, so let’s hope it survives.
8.1.4: Note that in your chart, you may wish to split out C and C++ support. Clang supports
_BitIntas an extension in C++, but GCC does not (due in part to them having separate frontends). So saying ‘GCC’ is perhaps confusing.
Done. I’ve added a column for which columns are supported.