View mode: basic / threaded / horizontal-split · Log in · Help
May 06, 2012
Re: Integer overflow and underflow semantics
On Saturday, 5 May 2012 at 05:32:14 UTC, Era Scarecrow wrote:

>  Any systems that implement a carry flag likely works exactly 
> like that.

Yes, but that misses the actual problem!

The problem isn't the _system_, it's the _compiler_.

If the language says overflow or underflow are undefined
behavior, then what the system does _doesn't matter one bit_,
because the compiler can optimize away the code entirely:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
May 06, 2012
Re: Integer overflow and underflow semantics
On Sunday, 6 May 2012 at 16:39:02 UTC, Mehrdad wrote:
> Yes, but that misses the actual problem!
>
> The problem isn't the _system_, it's the _compiler_.
>
> If the language says overflow or underflow are undefined 
> behavior, then what the system does _doesn't matter one bit_, 
> because the compiler can optimize away the code entirely:

 I know; as long as the number is within bounds it won't have any 
issues. hopefully a simple suggestion would be to add a compiler 
flag to check all results against overflow/underflow, of 
add/subtract/multiply; and should it happen it throws an 
exception; but asserts can likely do the same job if you have a 
critical section you needed checked.

 Under this case if you needed specific behavior you could use 
the asm{} blocks, but as a whole I don't know. :(

 I know I brought something similar to this before walter 
regarding the carry bit and overflow and if you could have finer 
control over it; but that ended up being rejected under the same 
idea that if you really needed that control you can use the asm{} 
block (I think, it's been a year or two I think).

 It would be tedious to add checks after every instruction, so 
the compiler would need to do it if you wanted those checks. 
Either a flag would need to be set after a certain point in the 
module that says 'act this way with math operations involving 
over/underflow', or it is forced inside certain blocks as a new 
try/catch, except... that might be

 trysys {
 a = b + c;
 } catch (Carry c) {
 //fix or whatever

 //since we know it's a carry flag we don't need c
 //so maybe catchsys(carry) instead??
 }

 Which might take an exception/like approach. But that seems 
doubtful, since very likely the cases where it's needed is very 
very very rare and refers back to asm or manual checks.

 a = b + c;
 if (a < b+c) {
 //overflow?
 //fails if MMX
 }
or
 if (a - b != c) {
 //overflow?
}

 Mmmm... Unfortunately I only have a few ideas and nothing 
concrete.
May 07, 2012
Re: Integer overflow and underflow semantics
On 05/05/12 06:57, Alex Rønne Petersen wrote:
> Hi,
>
> I don't think the language really makes it clear whether overflows and
> underflows are well-defined. Do we guarantee that for any integral type
> T, T.max + 1 == T.min and T.min - 1 == T.max?
>
> This is relevant in particular for GDC and LDC since they target a lot
> of weird architectures.
>

I think the reason that C makes no guarantees, was because of 
ones-complement machines (which had become very rare even by 1970).
Surely we can assume 2-s complement behaviour?
May 07, 2012
Re: Integer overflow and underflow semantics
On 07-05-2012 10:05, Don Clugston wrote:
> On 05/05/12 06:57, Alex Rønne Petersen wrote:
>> Hi,
>>
>> I don't think the language really makes it clear whether overflows and
>> underflows are well-defined. Do we guarantee that for any integral type
>> T, T.max + 1 == T.min and T.min - 1 == T.max?
>>
>> This is relevant in particular for GDC and LDC since they target a lot
>> of weird architectures.
>>
>
> I think the reason that C makes no guarantees, was because of
> ones-complement machines (which had become very rare even by 1970).
> Surely we can assume 2-s complement behaviour?

That's what I'm thinking. I can't even name a one's complement machine 
still in use today.

-- 
- Alex
May 09, 2012
Re: Integer overflow and underflow semantics
On Monday, 7 May 2012 at 08:06:01 UTC, Don Clugston wrote:
> I think the reason that C makes no guarantees, was because of 
> ones-complement machines

Maybe but that's not the full reason, as Mehrdad says the 
compiler can use the fact that overflow are undefined to optimise 
the code generated.

In my opinion, there are only two valid options for the integer 
operation's overflow by default: either the compiler should make 
sure that the overflow is noticed (Ada: exception, adding 
'Not-a-Number' values would work too) or C's signed undefined 
behaviour.
Modulo operation (except where really useful) are bad: slower 
than the 'undefined' semantic, yet it still produce obviously 
incorrect behaviour such as negative absolute value..
May 14, 2012
Re: Integer overflow and underflow semantics
On 05-05-2012 06:57, Alex Rønne Petersen wrote:
> Hi,
>
> I don't think the language really makes it clear whether overflows and
> underflows are well-defined. Do we guarantee that for any integral type
> T, T.max + 1 == T.min and T.min - 1 == T.max?
>
> This is relevant in particular for GDC and LDC since they target a lot
> of weird architectures.
>

Bumping this as we still need to make a decision about this. As recently 
as yesterday, someone on the GCC mailing list posted a complaint about 
an optimization pass that assumed undefined semantics for overflow. We 
need to have a stance about this, since GDC is going into mainline GCC soon.

-- 
- Alex
May 18, 2012
Re: Integer overflow and underflow semantics
>
> Bumping this as we still need to make a decision about this. As 
> recently as yesterday, someone on the GCC mailing list posted a 
> complaint about an optimization pass that assumed undefined 
> semantics for overflow. We need to have a stance about this, 
> since GDC is going into mainline GCC soon.

Just jumping into the bandwagon with several info:

http://en.wikipedia.org/wiki/Therac

Therac25 was a medicale machine that injured several people 
because:

"When input parameters are unverified or inconsistent,
the treatment monitor task periodically runs a procedure
that increments a counter
This counter is used as a flag by the housekeeping task,
indicating whether gun firing should be enabled or not
However, as the counter is only 8 bits, it will overflow
every 256 ticks, and the “flag” will temporarily indicate a
zero condition!
If the “set” command is given at that instant,
inconsistencies are not checked, and unshielded high-
energy radiation may result"

The case is known in the real-time operating systems programming.

Does D throw an exception when an integral type (signed or 
unsigned) underflows or overflows? I am for defining this as the 
implicit behavior. Using a counter in the cyclical mode should be 
rather be explicitly invoked.
May 18, 2012
Re: Integer overflow and underflow semantics
On 18-05-2012 15:26, akaz wrote:
>>
>> Bumping this as we still need to make a decision about this. As
>> recently as yesterday, someone on the GCC mailing list posted a
>> complaint about an optimization pass that assumed undefined semantics
>> for overflow. We need to have a stance about this, since GDC is going
>> into mainline GCC soon.
>
> Just jumping into the bandwagon with several info:
>
> http://en.wikipedia.org/wiki/Therac
>
> Therac25 was a medicale machine that injured several people because:
>
> "When input parameters are unverified or inconsistent,
> the treatment monitor task periodically runs a procedure
> that increments a counter
> This counter is used as a flag by the housekeeping task,
> indicating whether gun firing should be enabled or not
> However, as the counter is only 8 bits, it will overflow
> every 256 ticks, and the “flag” will temporarily indicate a
> zero condition!
> If the “set” command is given at that instant,
> inconsistencies are not checked, and unshielded high-
> energy radiation may result"
>
> The case is known in the real-time operating systems programming.
>
> Does D throw an exception when an integral type (signed or unsigned)
> underflows or overflows? I am for defining this as the implicit
> behavior. Using a counter in the cyclical mode should be rather be
> explicitly invoked.
>

I think this counts as sloppy programming if anything.

I agree that throwing an exception could be a good feature to have, but 
it should *not* be the default. I want my systems code to run at full 
speed when I know what I'm doing.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 18, 2012
Re: Integer overflow and underflow semantics
> I agree that throwing an exception could be a good feature to 
> have, but it should *not* be the default. I want my systems 
> code to run at full speed when I know what I'm doing.

In the release version, yes. In the release version, array bound 
checking is disabled, too.

But in the debug version?
May 18, 2012
Re: Integer overflow and underflow semantics
On 18-05-2012 19:28, akaz wrote:
>> I agree that throwing an exception could be a good feature to have,
>> but it should *not* be the default. I want my systems code to run at
>> full speed when I know what I'm doing.
>
> In the release version, yes. In the release version, array bound
> checking is disabled, too.
>
> But in the debug version?

It should be controllable with a command line option just as 
-noboundscheck. I'll revise what I said: It can be on in debug for all I 
care, as long as I can disable it independently of what mode I'm 
compiling in.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
1 2 3
Top | Discussion index | About this forum | D home