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

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.

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?

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

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..

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

>
> 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.

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

> 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?

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