Daniel Keep wrote:
bearophile wrote:
...
A possible use is for runtime test for overflows: you can perform
operations among 64 bit integers with 128 bit precision, and then you
can look at the result if it fits still in 64 bits. If not, you can
raise an overflow exception (probably there other ways to test for
overflow, but this seems simple to implement). You can use 64 bits to
implement the safe operations among 32-16-8 bit numbers on the 64 bit
CPUs).
Bye,
bearophile
It's always annoyed me that the CPU goes to all the trouble of doing
multiplies in 64-bit, keeping track of overflows, etc., and yet there's
no way in any language I've ever seen (aside from assembler) to get that
information.
Personally, rather than working around the problem with 128-bit types,
I'd prefer to see something (roughly) like this implemented:
bool overflow;
ubyte high;
ubyte a = 128;
// overflow == false
pragma(OverflowFlag, overflow) ubyte c = a + a;
// overflow == true
// high == 0
pragma(ResultHigh, high) ubyte d = a * 2;
// high == 1, d == 0
As for 128-bit types themselves, I'm sure *someone* would find a use for
them, and they'd be their favourite feature. Personally, I prefer
arbitrary-precision once you start getting that big, but there you go.
If 128-bit built-in integer can't be made more efficient by moving them
in the core, then the question is really "do you need 128-bit literals?"
because that's all the built-in feature would bring over a library.
Andrei
