https://github.com/D-Programming-Language/druntime/pull/839

While being a very modest piece of code in and of itself, I believe this offers a significant opportunity that both D compilers and user defined types can exploit.

Not only can it be used to create an efficient safeint data type, it can be used to implement multi-precision integer arithmetic types.

I'd also like to see it used to replace the various ad-hoc schemes currently in use. It should also be used in dmd itself for things like detecting array size overflows, which is currently done ad-hoc, and detecting overflows in CTFE.

For background information and rationale, see http://blog.regehr.org/archives/1139

Walter Bright:

> https://github.com/D-Programming-Language/druntime/pull/839

Why aren't functions with ubyte/byte/short/ushort arguments included?

--------------

Here Lionello Lunesu has suggested a __traits(valueRange, <expression>) for built-in values:
http://forum.dlang.org/thread/lnrc8l$1254$1@digitalmars.com

Once such trait is working on checkedint values, can this help the compiler remove some useless tests and increase the performance of checked ints?


> it can be used to implement multi-precision integer arithmetic types.

It looks very useful for the "small value optimization" for BigIntegers, to not allocate on the heap when the numbers are small, and switch to the heap allocation when they grow.

If you use such improved bigintegers to write code that is not supposed to overflow the range of normal integers, you obtain code that is only moderately slower than using checkedints, but it also gives the correct results if some overflow has occurred :-)

Bye,
bearophile

On 6/18/2014 2:43 AM, bearophile wrote:
> Walter Bright:
>
>> https://github.com/D-Programming-Language/druntime/pull/839
>
> Why aren't functions with ubyte/byte/short/ushort arguments included?

Because there is no ubyte/byte/short/ushort math in C, C++ or D. There is only int/long math.

Walter Bright:

> Because there is no ubyte/byte/short/ushort math in C, C++ or D. There is only int/long math.

A little of ubyte math is present, perhaps for this you add "uinc", "sinc", "udec", "sdec" functions to core.checkedint that support ubyte/byte/short/ushort types too:

void main() {
    ubyte x = 100;
    x++;
}


But you are right, in D if you sum two ubytes you get an int:

void main() {
    ubyte x = 100;
    ubyte y = 200;
    pragma(msg, typeof(x + y)); // Prints "int"
}


Yet sometimes you want to perform safe math operations on ubytes/bytes/shorts/ushorts, and keep the same type for the results. So I presume a future Phobos Safe math based on core.checkedint will need to check the ranges by itself, to allow checked assignments back to the same types:

void main() {
    Safe!ubyte x = 100;
    Safe!ubyte y = 200;
    Safe!ubyte z = x + y;
}

Bye,
bearophile

On Wednesday, 18 June 2014 at 01:26:16 UTC, Walter Bright wrote:
> https://github.com/D-Programming-Language/druntime/pull/839

I think the mulu implementation is incorrect. There can be an overflow even when r = 0. For example consider the int version with x = y = 1<<16.

On Thursday, 19 June 2014 at 03:42:11 UTC, David Bregman wrote:
> I think the mulu implementation is incorrect. There can be an overflow even when r = 0. For example consider the int version with x = y = 1<<16.

I also noticed this; another easy counter-example would be 1<<32 for ulong multiplication.

Filed as: https://issues.dlang.org/show_bug.cgi?id=12958

> While being a very modest piece of code in and of itself, I believe this offers a significant opportunity that both D compilers and user defined types can exploit.

I did this in C/C++ a while ago, out of which I have forgotten most of it :)

https://github.com/nordlow/justcxx/blob/master/sadd.h
https://github.com/nordlow/justcxx/blob/master/ssub.h
https://github.com/nordlow/justcxx/blob/master/smul.h

Tests are here:
https://github.com/nordlow/justcxx/blob/master/t_ranged_and_saturated.cpp

Maybe there's something more here that could give further ideas.

Pick what you want.

On 6/22/2014 12:37 AM, "Nordlöw" wrote:
>> While being a very modest piece of code in and of itself, I believe this
>> offers a significant opportunity that both D compilers and user defined types
>> can exploit.
>
> I did this in C/C++ a while ago, out of which I have forgotten most of it :)
>
> https://github.com/nordlow/justcxx/blob/master/sadd.h
> https://github.com/nordlow/justcxx/blob/master/ssub.h
> https://github.com/nordlow/justcxx/blob/master/smul.h
>
> Tests are here:
> https://github.com/nordlow/justcxx/blob/master/t_ranged_and_saturated.cpp
>
> Maybe there's something more here that could give further ideas.
>
> Pick what you want.

Thank you, that's very generous.

Will this be in the 2.066 Beta?

On Wednesday, 18 June 2014 at 01:26:16 UTC, Walter Bright wrote:
> https://github.com/D-Programming-Language/druntime/pull/839
>
> While being a very modest piece of code in and of itself, I believe this offers a significant opportunity that both D compilers and user defined types can exploit.
>
> Not only can it be used to create an efficient safeint data type, it can be used to implement multi-precision integer arithmetic types.
>
> I'd also like to see it used to replace the various ad-hoc schemes currently in use. It should also be used in dmd itself for things like detecting array size overflows, which is currently done ad-hoc, and detecting overflows in CTFE.
>
> For background information and rationale, see http://blog.regehr.org/archives/1139

On Tuesday, 1 July 2014 at 22:07:01 UTC, Paul D Anderson wrote:
> Will this be in the 2.066 Beta?

It's currently in Git master, so yes – but we definitely need to fix https://issues.dlang.org/show_bug.cgi?id=12958 before the release (mul is horribily broken).

David