Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support):

http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642

Bye,
bearophile

On 05.12.2011 14:31, bearophile wrote:
> Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support):
>
> http://blog.regehr.org/archives/641
> http://blog.regehr.org/archives/642
>
> Bye,
> bearophile

Not very convincing, since he proposes a change to existing architectures, and seems completely unaware of the overflow flag.
If you can change existing architectures, why not simply allow an exception to be generated if an overflow occurs?

Doesn't seem at all helpful to D.

I can agree that in some circumstances, a ranged and saturated integer mode
would be REALLY handy (colours, sound samples), but I can't buy in with the
whole trapping overflows and stuff... most architectures will require
explicit checking of the overflow bit after every operation to support
this. Also, contrary to his claim, I find that wrapping is usually what I
DO want in this case..
It's super rare that I write any code that pushes the limits of an int
(unless we're talking 8-16 bit, see my range+saturation comment before),
and when I do write code that pushes the range of an int, I can't think of
a time when I've not wanted to wrap as expected. If I'm dealing with
integers that big, chances are I'm dealing with memory ranges, bit masks,
or some compression/crypto type thing where the algorithms depend on it.
Not only am I aware of the wrapping behaviour, it's usually the intent...

On 5 December 2011 18:37, Don <nospam@nospam.com> wrote:

> On 05.12.2011 14:31, bearophile wrote:
>
>> Found through Reddit, two blog posts about how integers should behave in system languages (with hardware support):
>>
>> http://blog.regehr.org/**archives/641<http://blog.regehr.org/archives/641> http://blog.regehr.org/**archives/642<http://blog.regehr.org/archives/642>
>>
>> Bye,
>> bearophile
>>
>
> Not very convincing, since he proposes a change to existing architectures,
> and seems completely unaware of the overflow flag.
> If you can change existing architectures, why not simply allow an
> exception to be generated if an overflow occurs?
>
> Doesn't seem at all helpful to D.
>

On 12/5/11 10:37 AM, Don wrote:
> On 05.12.2011 14:31, bearophile wrote:
>> Found through Reddit, two blog posts about how integers should behave
>> in system languages (with hardware support):
>>
>> http://blog.regehr.org/archives/641
>> http://blog.regehr.org/archives/642
>>
>> Bye,
>> bearophile
>
> Not very convincing, since he proposes a change to existing
> architectures, and seems completely unaware of the overflow flag.
> If you can change existing architectures, why not simply allow an
> exception to be generated if an overflow occurs?
>
> Doesn't seem at all helpful to D.

Agreed. One thought that comes to mind is using the small int optimization for BigInt, i.e. use no dynamic allocation and built-in operations whenever possible if the value is small enough. Does BigInt currently do that?

Andrei

On 12/05/2011 06:25 PM, Andrei Alexandrescu wrote:
> On 12/5/11 10:37 AM, Don wrote:
>> On 05.12.2011 14:31, bearophile wrote:
>>> Found through Reddit, two blog posts about how integers should behave
>>> in system languages (with hardware support):
>>>
>>> http://blog.regehr.org/archives/641
>>> http://blog.regehr.org/archives/642
>>>
>>> Bye,
>>> bearophile
>>
>> Not very convincing, since he proposes a change to existing
>> architectures, and seems completely unaware of the overflow flag.
>> If you can change existing architectures, why not simply allow an
>> exception to be generated if an overflow occurs?
>>
>> Doesn't seem at all helpful to D.
>
> Agreed. One thought that comes to mind is using the small int
> optimization for BigInt, i.e. use no dynamic allocation and built-in
> operations whenever possible if the value is small enough. Does BigInt
> currently do that?
>
> Andrei

It does not.

Andrei Alexandrescu:

> Agreed. One thought that comes to mind is using the small int optimization for BigInt, i.e. use no dynamic allocation and built-in operations whenever possible if the value is small enough. Does BigInt currently do that?

Both the small int optimization (32 or 64 bit? To be decided still), and the memory pool for bigints are not yet implemented. This also means the recent suggested improvements of the GC are able to improve the  performance of code that use BigInts (I have already verified it).

Bye,
bearophile

Manu:

> Also, contrary to his claim, I find that wrapping is usually what I
> DO want in this case..
> It's super rare that I write any code that pushes the limits of an int
> (unless we're talking 8-16 bit, see my range+saturation comment before),
> and when I do write code that pushes the range of an int, I can't think of
> a time when I've not wanted to wrap as expected.

The code you usually write seems rather unusual. I have kind of the opposite situations.

But first of all, "trapping" ints are needed to avoid bugs in normal code. Some bugs are shown here: http://embed.cs.utah.edu/ioc/

Bye,
bearophile

>
> Manu:
>
> > Also, contrary to his claim, I find that wrapping is usually what I
> > DO want in this case..
> > It's super rare that I write any code that pushes the limits of an int
> > (unless we're talking 8-16 bit, see my range+saturation comment before),
> > and when I do write code that pushes the range of an int, I can't think
> of
> > a time when I've not wanted to wrap as expected.
>
> The code you usually write seems rather unusual. I have kind of the opposite situations.
>
> But first of all, "trapping" ints are needed to avoid bugs in normal code.
> Some bugs are shown here:
> http://embed.cs.utah.edu/ioc/


I write C/C++ systems/embedded/games code (not a small industry by any measure), and I'm looking to D as a successor.. I'm NOT interested in D as a replacement for C# (or Java/etc), those languages already exist, are well supported, and I'm happy with them for their purpose. I realise I seem to be one of the odd ones out on this forum currently, hence I like to throw my 2c in from time to time :) .. but I don't believe I'm alone.. the rest of the gamedev community will find D soon enough if the language gets it right...

I did see some examples of the common overflow bugs via links in your OP, but I just have never run into those problems myself.. A couple of them depended on an actual bug in your code. for instance this one:

*result = result * 10 + cursor - '0';*

Should have been:

*result * 10 + (cursor - '0')*

This isn't a legitimate runtime error, it's compile time/logic bug. Perhaps a warning should be generated at compile time if the logic can be deduced... (probably impossible)

If you're suggesting the reason for trapping overflow's is specifically to CATCH bugs like this, then maybe make is a compiler flag when building a debug binary? (ie. assert on integer overflow).

Manu:

> but I don't believe I'm alone.. the rest
> of the gamedev community will find D soon enough if the language gets it
> right...

I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games.


> If you're suggesting the reason for trapping overflow's is specifically to CATCH bugs like this, then maybe make is a compiler flag when building a debug binary? (ie. assert on integer overflow).

Right.


I think D2/D3 has also a bit of hope to replace some of the purposes of Ada language. Walter maybe didn't think of it when he designed D, but D shares some design purposes with Ada. Walter past work in aeronautical engineering leads naturally to a language that shares some of the purposes of Ada. For such purposes correctness and reliability are of the highest importance, this also means full type safety (implicit type conversions = bad) and number safety (integral overflows = bad). Defining something like a "MISRA-D" (a strict and safe subset of D similar to MISRA-C) is an option, and maybe it will produce a less butchered language.

Bye,
bearophile

On 12/5/2011 5:31 AM, bearophile wrote:
> Found through Reddit, two blog posts about how integers should behave in
> system languages (with hardware support):
>
> http://blog.regehr.org/archives/641 http://blog.regehr.org/archives/642
>
> Bye, bearophile

Lotsa good comments on HN:

http://news.ycombinator.com/item?id=3312101