www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Hardware Traps for Integer Overflow

reply "bearophile" <bearophileHUGS lycos.com> writes:
A request for hardware overflow tests:
http://blog.regehr.org/archives/1154

 From the blog post:


Processors should support integer math instructions that 
optionally trap on overflow. Because popular architectures lack 
this feature, otherwise excellent modern systems programming 
languages, such as Rust, Go, and D, have default integer types 
that wrap.<



This post isn’t as much of an opinion piece as a plea to the 
folks at ARM, Intel, and AMD: Please provide this feature. It is 
needed in order to make high-level languages faster and 
low-level languages saner.<


 From the comments:


I’ve grown to dislike unsigned types but agree that they are a 
perfectly valid design point in a language that avoids the 
serious problems with implicit coercion that C/C++ have. Rust 
gets unsigned right, for example.<


Bye,
bearophile
May 29 2014
parent reply "Wanderer" <no-reply no-reply.org> writes:
I don't see any valid alternatives. What should ideally happen if 
you increment 0xFFFF..FFFF? Should the value remain the same? 
That's not much better than resetting back to zero, still a 
mathematical error. Throw an exception? That would kill 
performance and break lots of existing code.

If you need perfect calculations, you can always use an according 
library for numbers with arbitrary precision.
May 29 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Wanderer:


 If you need perfect calculations, you can always use an 
 according library for numbers with arbitrary precision.


The D Zen points in the opposite direction: if you don't care of 
having bogus results in your code, then use unsafe integers :-)

Bye,
bearophile
May 29 2014
prev sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Thursday, 29 May 2014 at 15:32:54 UTC, Wanderer wrote:

 I don't see any valid alternatives. What should ideally happen 
 if you increment 0xFFFF..FFFF? Should the value remain the same?


I know at least one firmware running in cars from several 
manufacturers where
this is the desired behavior in dozens of places. Saturated 
arithmetic is common.

(I'm not saying it should be the default)
May 29 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 29 May 2014 at 20:01:25 UTC, Tobias Pankrath wrote:

 On Thursday, 29 May 2014 at 15:32:54 UTC, Wanderer wrote:

 I don't see any valid alternatives. What should ideally happen 
 if you increment 0xFFFF..FFFF? Should the value remain the 
 same?


 I know at least one firmware running in cars from several 
 manufacturers where
 this is the desired behavior in dozens of places. Saturated 
 arithmetic is common.

 (I'm not saying it should be the default)


There are dedicated instruction in more recent versions of SSE 
for saturated arithmetic.
May 29 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 29 May 2014 20:10:13 +0000
schrieb "John Colvin" <john.loughran.colvin gmail.com>:


 On Thursday, 29 May 2014 at 20:01:25 UTC, Tobias Pankrath wrote:

 On Thursday, 29 May 2014 at 15:32:54 UTC, Wanderer wrote:

 I don't see any valid alternatives. What should ideally happen 
 if you increment 0xFFFF..FFFF? Should the value remain the 
 same?


 I know at least one firmware running in cars from several 
 manufacturers where
 this is the desired behavior in dozens of places. Saturated 
 arithmetic is common.

 (I'm not saying it should be the default)


 
 There are dedicated instruction in more recent versions of SSE 
 for saturated arithmetic.


Actually  such instructions exist since MMX on Intel CPUs. The
question is: Can these new SSE instructions replace integer
math seemlessly?

-- 
Marco
May 30 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 30 May 2014 at 07:00:58 UTC, Marco Leise wrote:

 Am Thu, 29 May 2014 20:10:13 +0000
 schrieb "John Colvin" <john.loughran.colvin gmail.com>:


 On Thursday, 29 May 2014 at 20:01:25 UTC, Tobias Pankrath 
 wrote:

 On Thursday, 29 May 2014 at 15:32:54 UTC, Wanderer wrote:

 I don't see any valid alternatives. What should ideally 
 happen if you increment 0xFFFF..FFFF? Should the value 
 remain the same?


 I know at least one firmware running in cars from several 
 manufacturers where
 this is the desired behavior in dozens of places. Saturated 
 arithmetic is common.

 (I'm not saying it should be the default)


 
 There are dedicated instruction in more recent versions of SSE 
 for saturated arithmetic.


 Actually  such instructions exist since MMX on Intel CPUs. The
 question is: Can these new SSE instructions replace integer
 math seemlessly?


As user-defined types in D it can definitely be done, although it 
probably wouldn't be performant for single small ints. I have a 
127bit SIMD integer type struct that I use occasionally, which 
could quite easily be made saturating without degrading 
performance much (if at all, I don't know how fast those 
saturating instructions are).

Obviously that doesn't change the language builtin types who will 
still happily wrap-around.
May 30 2014
prev sibling parent "Wanderer" <no-reply no-reply.org> writes:
 Actually  such instructions exist since MMX on Intel CPUs. The
 question is: Can these new SSE instructions replace integer
 math seemlessly?


My opinion is "no". When you increment an integer value (any 
value), you at least expect its lower bit to change. All 
cryptographic algorithms would crash in a second if operations 
would neglect fraction of values.
May 30 2014