473,287 Members | 2,263 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

Catching integer overflow

Is it possible to use some C or compiler extension to catch
integer overflow?

The situation is as follows:
I use C as target language for compiled Seed7 programs.
For integer computions the C type 'long' is used.
That way native C speed can be reached.

Now I want to experiment with raising a Seed7 exception
(which is emulated with setjmp(), longjmp() in C) for integer
overflow. Since the C int's and long's have undefined
behaviour on overflow, I hope to use some C or compiler
extensions to implement the overflow exceptions.

I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

Normal C programs which do integer computations should
have no overhead. When an overflow happens a signal or
something else should happen that I can use to emulate
an exception.

Are there ideas to solve this problem?

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 16 '08 #1
42 6938
<th***********@gmx.atwrote in message
news:e2**********************************@d77g2000 hsb.googlegroups.com...
Is it possible to use some C or compiler extension to catch
integer overflow?
I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.
I don't think an integer overflow would typically cause a hardware
exception.

So this is down to using extra instructions, usally /after/ the operation.

This need not be a high overhead, if you were targetting x86 instead of C,
you might use 'jo label' after the add.

But C doesn't normally have this sort of thing built-in, unless it's in the
form of special compiler extensions and switches. In your case, you cannot
rely on this because your application then becomes compiler-specific (you
might as well rely on inline Asm).

There might be a few workarounds in C, but I guess they all have overheads
of some kind.

What is the purpose of this overflow check? To switch over to large integer
form? Otherwise overflow checking could be optional for the user.

--
Bartc

Jul 16 '08 #2
On 16 Jul., 11:51, "Bartc" <b...@freeuk.comwrote:
<thomas.mer...@gmx.atwrote in message

news:e2**********************************@d77g2000 hsb.googlegroups.com...
Is it possible to use some C or compiler extension to catch
integer overflow?
I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

I don't think an integer overflow would typically cause a hardware
exception.
Maybe it is possible to switch the hardware to a some
mode where an interrupt is raised with an integer overflow.
In that case the code for the mode switch and the
interrupt handler would be compiler/os dependend, but
the rest of the program would be plain C.
So this is down to using extra instructions, usally /after/ the operation.

This need not be a high overhead, if you were targetting x86 instead of C,
you might use 'jo label' after the add.
Is 'jo' an actual x86 instruction meaning "Jump when overflow
flag is set"?
But C doesn't normally have this sort of thing built-in, unless it's in the
form of special compiler extensions and switches. In your case, you cannot
rely on this because your application then becomes compiler-specific (you
might as well rely on inline Asm).
I know that this will probably be compiler-specific.
This is just a thing I want to explore.
What about C99 or the next C standard?
There might be a few workarounds in C, but I guess they all have overheads
of some kind.

What is the purpose of this overflow check? To switch over to large integer
form? Otherwise overflow checking could be optional for the user.
It is not my intention to switch to larger integers
on the fly. I just want to avoid undefined behaviour.

The C89 Ansi C standard states:
The handling of overflow, divide check and other exceptions
in expression evaluation is not defined by the language.
Most existing implementations of C ignore overflow in
evaluation of signed integral expressions and assignments,
but this behavior is not guaranteed.

I think that exceptions for integer overflows could
also be helpful to find bugs.

Like other range checks (for array or string access) it
could be made optional. A compiler switch or pragma could
be used to switch it on or off.

Currently I am still hoping for a zero overhead solution.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 16 '08 #3
th***********@gmx.at wrote:
Is it possible to use some C or compiler extension to catch
integer overflow?
lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.

Obviously you should separate your operations if
you are insterested in knowing which operation overflowed.

For instance:

int a,b,c;

c = (a+b)*c;

If the overflow flag is set, it means that the multiplication
overflowed, but it is impossible to know if the addition
overflowed.

lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.

The situation is as follows:
I use C as target language for compiled Seed7 programs.
For integer computions the C type 'long' is used.
That way native C speed can be reached.
lcc-win is specially adapted for use as a back end compiler. A JIT
compiler is also available (you just pass a C code character
string instead of a file)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jul 16 '08 #4
<th***********@gmx.atwrote in message
news:0f**********************************@s50g2000 hsb.googlegroups.com...
On 16 Jul., 11:51, "Bartc" <b...@freeuk.comwrote:
><thomas.mer...@gmx.atwrote in message

news:e2**********************************@d77g200 0hsb.googlegroups.com...
Is it possible to use some C or compiler extension to catch
integer overflow?
I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

I don't think an integer overflow would typically cause a hardware
exception.

Maybe it is possible to switch the hardware to a some
mode where an interrupt is raised with an integer overflow.
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
>This need not be a high overhead, if you were targetting x86 instead of
C,
you might use 'jo label' after the add.

Is 'jo' an actual x86 instruction meaning "Jump when overflow
flag is set"?
Yes, in Nasm syntax anyway. For unsigned overflow a different condition
(jc?) is used. Except of course in C unsigned overflow is an impossibility.

--
Bartc
Jul 16 '08 #5
th***********@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?
<off-topic>
gcc has -ftrapv -- probably only when the target can do it
efficiently.

Presumably you don't use gcc or you'd have found it in the man page ;-)
</off-topic>

--
Ben.
Jul 16 '08 #6
thomas.mer...@gmx.at wrote:
Is it possible to use some C or compiler extension to catch
integer overflow?
Have you thought about being portably proactive rather than
non-portably reactive with regards to overflow?

--
Peter
Jul 16 '08 #7
>Now I want to experiment with raising a Seed7 exception
>(which is emulated with setjmp(), longjmp() in C) for integer
overflow. Since the C int's and long's have undefined
behaviour on overflow, I hope to use some C or compiler
extensions to implement the overflow exceptions.

I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

Normal C programs which do integer computations should
have no overhead. When an overflow happens a signal or
something else should happen that I can use to emulate
an exception.
I don't think your goal of *NO* overhead is possible, even in most
assembly languages (and in particular, not on x86). It may be
possible with floating point, as you can enable exceptions to cause
traps. Some of this is even controllable in C by IEEE floating-point
extensions. (Although I am *not* sure that enabling exceptions
doesn't slow down the instruction a bit even when there isn't an
exception taken) But not with integer calculations.

On x86, you can't use instructions like branch-on-overflow or
trap-on-overflow because they are instructions and cause overhead.
You demanded no overhead.

*IF* you could get the compiler to place a trap-on-overflow
instruction after each signed integer calculation (but not on
the unsigned integer calculations), and you catch whatever
signal the trap-on-overflow instruction generates, that's
probably the best you can get. You'll still have overhead.

Jul 17 '08 #8
"Bartc" <bc@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]

You'd rather have wrong answers quickly?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 17 '08 #9

"Gordon Burditt" <go***********@burditt.orgwrote in message
news:D5******************************@posted.inter netamerica...
Now I want to experiment with raising a Seed7 exception
(which is emulated with setjmp(), longjmp() in C) for integer
overflow.
>>Normal C programs which do integer computations should
have no overhead.
On x86, you can't use instructions like branch-on-overflow or
trap-on-overflow because they are instructions and cause overhead.
You demanded no overhead.

*IF* you could get the compiler to place a trap-on-overflow
instruction after each signed integer calculation (but not on
the unsigned integer calculations),
This is for implementing a different language, which could well have the
concept of unsigned overflow:

If my unsigned int can only store 0..9, I may want to know that 5+7 only
gave me 2 instead of the correct 12.

--
Bartc
Jul 17 '08 #10

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Bartc" <bc@freeuk.comwrites:
[...]
>I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]

You'd rather have wrong answers quickly?
Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

But if there is a hardware trap (like divide by zero) that didn't slow
things down, then that's fine, provided the overflow was a genuine error. I
can see that being difficult to implement however, unless you also have
separate arithmetic instructions for signed and unsigned values.

--
Bartc
Jul 17 '08 #11
Bartc wrote:
>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>"Bartc" <bc@freeuk.comwrites:
[...]
>>I don't know. Integer overflow doesn't seem serious enough to
warrant hardware support.
[...]

You'd rather have wrong answers quickly?

Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

But if there is a hardware trap (like divide by zero) that didn't slow
things down,
Traps and interrupts actually incur *much* more delay than doing the
detection manually, since under modern systems a trap involves a
context switch and then a signal needs to be delivered to your process,
all of which take more time than a few checks before doing the
operation.

The problem of course is similar to checking return values versus
exceptions. Traps only fire when an overflow actually occurs while
manual checks will slowdown all calculations.

I think that using a lot of #ifdef trickery it's possible to use the
best methods available for each compiler or fall back plain C code when
nothing is available. But it's a lot of work.

<snip>

Jul 17 '08 #12

"santosh" <sa*********@gmail.comwrote in message
news:g5**********@registered.motzarella.org...
Bartc wrote:
>>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>>"Bartc" <bc@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to
warrant hardware support.
[...]

You'd rather have wrong answers quickly?

Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

But if there is a hardware trap (like divide by zero) that didn't slow
things down,

Traps and interrupts actually incur *much* more delay than doing the
detection manually, since under modern systems a trap involves a
context switch and then a signal needs to be delivered to your process,
all of which take more time than a few checks before doing the
operation.
I'm assuming the overflow is a rare event. If the program relies on frequent
overflow traps for it's operation then it might as well use extra C code or
get the compiler to insert appropriate instructions. This is better because
you don't get traps occuring in library code or anywhere else just because
/your/ program requires them.

--
Bartc
Jul 17 '08 #13
"Bartc" <bc@freeuk.comwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>"Bartc" <bc@freeuk.comwrites:
[...]
>>I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]

You'd rather have wrong answers quickly?

Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.
[...]

Well, luckily for you, C does require overflow checking for operations
on signed integers, and mandates well-defined behavior when the checks
fail, and zero run-time overhead when they don't.

But you might want to verify that information. I though it was more
important to post a followup quickly than to get it right.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 17 '08 #14
On 17 Jul., 17:54, Keith Thompson <ks...@mib.orgwrote:
"Bartc" <b...@freeuk.comwrites:
"Keith Thompson" <ks...@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Bartc" <b...@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]
You'd rather have wrong answers quickly?
Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

[...]

Well, luckily for you, C does require overflow checking for operations
on signed integers, and mandates well-defined behavior when the checks
fail, and zero run-time overhead when they don't.
About which C you talking about?
The C89 Ansi C standard states:
The handling of overflow, divide check and other exceptions
in expression evaluation is not defined by the language.
Most existing implementations of C ignore overflow in
evaluation of signed integral expressions and assignments,
but this behavior is not guaranteed.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 17 '08 #15
On 17 Jul., 00:45, Peter Nilsson <ai...@acay.com.auwrote:
thomas.mer...@gmx.at wrote:
Is it possible to use some C or compiler extension to catch
integer overflow?

Have you thought about being portably proactive rather than
non-portably reactive with regards to overflow?
What do you mean with proactive?
Doing checks before every integer operation?

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 17 '08 #16
On 16 Jul., 13:14, jacob navia <ja...@nospam.comwrote:
thomas.mer...@gmx.at wrote:
Is it possible to use some C or compiler extension to catch
integer overflow?

lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.
Is checking the overflow flag the only possibility?
How is the overflow flag reset?
Would it be possible to minimize the checks for the flag?
Since I want to raise an exception, all integer variables
below the (stack) level of the exception handler could
theoretically contain wrong (overflowed) values without
having an infuence on the rest of the program.
lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.
Todays hardware does so many things.
Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?
The situation is as follows:
I use C as target language for compiled Seed7 programs.
For integer computions the C type 'long' is used.
That way native C speed can be reached.

lcc-win is specially adapted for use as a back end compiler. A JIT
compiler is also available (you just pass a C code character
string instead of a file)
Ok.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 17 '08 #17
On Jul 17, 4:54*pm, Keith Thompson <ks...@mib.orgwrote:
"Bartc" <b...@freeuk.comwrites:
"Keith Thompson" <ks...@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Bartc" <b...@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]
You'd rather have wrong answers quickly?
...
Well, luckily for you, C does require overflow checking for operations
on signed integers...
But you might want to verify that information. *I though it was more
important to post a followup quickly than to get it right.
We may be talking at cross purposes. It seems you are saying I posted
incorrect information? OK let's see:
>I don't know. [about exceptions on integer overflow]
Well I can verify that! Whether machines in general have an interrupt
setting to automatically trap signed integer overflow, without using
an explicit instruction per arithmetic operation, perhaps someone can
enlighten us.

Although as I've indicated in another post, such a global setting
would cause problems, since an Add-op for example is typically neither
signed or unsigned, so it would not know if this was a signed add or
not.
>Integer overflow doesn't seem serious enough to warrant
>hardware support. [Ie. automatically trap on overflow, not merely setflags]
That's my opinion. And again I can verify that.

--
Bartc
Jul 17 '08 #18
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?

gcc has -ftrapv -- probably only when the target can do it
efficiently.

Presumably you don't use gcc or you'd have found it in the man page ;-)
As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.

I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.

Can you confirm this?

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 17 '08 #19
th***********@gmx.at wrote:
On 16 Jul., 13:14, jacob navia <ja...@nospam.comwrote:
>thomas.mer...@gmx.at wrote:
>>Is it possible to use some C or compiler extension to catch
integer overflow?
lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.

Is checking the overflow flag the only possibility?
If you want to check for a specific operation yes.
If not, the compiler can introduce the check in ALL
arithmetic operations automatically. Then, you
do not check anything.
How is the overflow flag reset?
Each arithmetic operation resets the overflow flag to a new
value.
Would it be possible to minimize the checks for the flag?
If you check only the operations you are interested in,
fewer checks are done.
Since I want to raise an exception, all integer variables
below the (stack) level of the exception handler could
theoretically contain wrong (overflowed) values without
having an infuence on the rest of the program.
Only the last variable would contain an overflow, not
ALL of them. For instance:

int a,b,c;

c = a*b;

if (_overflow()) {
// The value of 'c' is wrong.
// a AND b are correct!
}
>lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.

Todays hardware does so many things.
Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?
Yes. There is an interrupt on overflow, opcode 0xCE. But you
will have to write an interrupt handler, and that is quite
difficult. You will also have to convince the operating
system to load your interrupt handler, etc.

Note that this instruction only works in 32 bit mode. In 64 bit mode
this instruction will provoke an illegal instrution exception...

Probably there is a mode for 64 bit overflow testing but I would
have to investigate the matter.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jul 17 '08 #20
On Jul 17, 8:09*pm, thomas.mer...@gmx.at wrote:
On 16 Jul., 13:14, jacob navia <ja...@nospam.comwrote:
thomas.mer...@gmx.at wrote:
Is it possible to use some C or compiler extension to catch
integer overflow?
lcc-win provides the extension:
bool _overflow();
that returns the value of the overflow flag.

Is checking the overflow flag the only possibility?
How is the overflow flag reset?
Would it be possible to minimize the checks for the flag?
This is all stuff for the compiler writer to worry about.
lcc-win also offers the
lcc -checkoverflow
flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.

Todays hardware does so many things.
Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?
Someone mentioned an INTO instruction but I think you use that
following your operation.

The problem with the x86 specifically, is that instructions such as
ADD work with both signed and unsigned values. An operation which sets
the (signed) overflow flag, may be fine for an unsigned operation. But
the cpu doesn't know which was intended.

You might enable/disable the setting around each operation, but that
will be quite an overhead.

--
Bartc
Jul 17 '08 #21
th***********@gmx.at writes:
On 17 Jul., 17:54, Keith Thompson <ks...@mib.orgwrote:
>"Bartc" <b...@freeuk.comwrites:
"Keith Thompson" <ks...@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Bartc" <b...@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]
>You'd rather have wrong answers quickly?
Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

[...]

Well, luckily for you, C does require overflow checking for operations
on signed integers, and mandates well-defined behavior when the checks
fail, and zero run-time overhead when they don't.

About which C you talking about?
The C89 Ansi C standard states:
The handling of overflow, divide check and other exceptions
in expression evaluation is not defined by the language.
Most existing implementations of C ignore overflow in
evaluation of signed integral expressions and assignments,
but this behavior is not guaranteed.
Sorry, I guess I was being more suble than I thought I was.

The paragraph I wrote above, starting with "Well, luckily for you", is
completely and deliberately false. I followed it with:

But you might want to verify that information. I though it was
more important to post a followup quickly than to get it right.

I was trying (apparently not completely successfully) to make a point
about the attitude that getting *quick* answers is more important than
getting *correct* answers, and drawing a parallel between performing
arithmetic without checking for overflow, and posting followups
without checking for accuracy.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 17 '08 #22
Bart <bc@freeuk.comwrites:
On Jul 17, 4:54*pm, Keith Thompson <ks...@mib.orgwrote:
>"Bartc" <b...@freeuk.comwrites:
"Keith Thompson" <ks...@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Bartc" <b...@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]
>You'd rather have wrong answers quickly?
...
>Well, luckily for you, C does require overflow checking for operations
on signed integers...
>But you might want to verify that information. *I though it was more
important to post a followup quickly than to get it right.

We may be talking at cross purposes. It seems you are saying I posted
incorrect information?
No, that's not what I was saying at all, and I apologize if I gave
that impression.

The incorrect information I was alluding to was the result of an
overflowing computation. My intent was to question the attitude that
getting this incorrect information as quickly as possible is more
important that detecting the fact that it's incorrect.

And yes, the fact that overflow detection has some significant
run-time overhead is a real issue.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 17 '08 #23
Keith Thompson wrote:
>
The incorrect information I was alluding to was the result of an
overflowing computation. My intent was to question the attitude that
getting this incorrect information as quickly as possible is more
important that detecting the fact that it's incorrect.

And yes, the fact that overflow detection has some significant
run-time overhead is a real issue.
lcc-win features this extension since at least 6-7 years...
The run time overhead is almost nothing, since it reduces to

o 1 more instruction (jump if overflow)
o in 99.999% of the case the jump is not taken.

If the compiler puts the overflow code at the end of the function,
in the x86 a forward jump will correctly be predicted as not taken...

The overhead is really minimal!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jul 17 '08 #24
Is it possible to use some C or compiler extension to catch
integer overflow?

lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.

Is checking the overflow flag the only possibility?
No, you could check whether you would have overflow before doing
the operation that causes overflow. This is generally a lot more
expensive than checking the overflow flag (on machines that have
one, and it does what you want in the situation). And the OP wanted
NO overhead unless there was overflow.
>How is the overflow flag reset?
Generally any operation that can overflow sets the flag on overflow
and resets it on no overflow. You cannot do a whole series of
operations and then check the overflow flag to determine if any of
them overflowed - that check will only check the last operation.
>Would it be possible to minimize the checks for the flag?
No, the overflow flag is not generally "sticky" (and is not
sticky for the x86).
>Since I want to raise an exception, all integer variables
below the (stack) level of the exception handler could
theoretically contain wrong (overflowed) values without
having an infuence on the rest of the program.
>lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.
Does this use the x86 trap-on-overflow instruction? If so, you can
do something that doesn't quite meet the OP's requirements, but is
probably about as close as you can get:

1. The compiler puts trap-on-overflow instructions after all signed
integer operations.
2. The trap for trap-on-overflow raises a signal. (Typically an
OS will assign a signal to any traps it doesn't otherwise do anythng
with, so this is done for you. I'm not sure what Windows does).
3. The program catches the signal from (2) and does something with it.

However, your overhead for no overflow is 1 trap-on-overflow
instruction (a few CPU clock cycles) for each calculation. What
was requested was NO overhead on no overflow and unspecified overhead
on overflow (say, 5 minutes to generate a core dump).

>Todays hardware does so many things.
And most of them require code to make it do what you want.
>Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?
Yes. And it won't trap when the zero flag is set, or when you load
EAX with a poor approximation of pi * 1000000, either. You have
to write code for that. Note also that there are NOT separate
signed and unsigned math instructions, and signed and unsigned
overflow are different (besides the issue that C defines unsigned
math with no overflow), so constant fiddling with the "interrupt
on overflow" flag would be needed. A compromise is the "trap-on-overflow"
instruction which lets you test specific operations.

Note that the designers of the floating-point instruction set had
more of this approach in mind. You can set bits for floating-point
exceptions on overflow, underflow, loss of significance, and division
by zero. Error flags can be made sticky, so you can avoid the
traps, just do a whole series of calculations and check at the end
to see whether you blew it.

I would hate to see traps for integer loss of significance (in other
words, the result of an operation is zero, so 2-2 would cause a
trap). It would be very difficult to get the C library to work
correctly with that set.
Jul 17 '08 #25
On Jul 17, 2:16*pm, Bart <b...@freeuk.comwrote:
Whether machines in general have an interrupt
setting to automatically trap signed integer overflow, without using
an explicit instruction per arithmetic operation, perhaps someone can
enlighten us.

Basically the answer is no. x86 basically does not, although there
are a couple of one instruction ways of detecting an overflow (JO and
INTO, the latter generating a trap). S/360..zSeries has a mode bit
which allows signed arithmetic instructions to generate traps (there
are separate unsigned instructions), although it's an all or nothing
thing, and is almost never turned on. Nor does it really cover all
situations, in that some instructions don't really generate overflows
in the sense that C would like them (for example, many of the multiply
and divide instructions). Alpha, IPF, 6502, Z-80, PIC, 8051, and ARM,
just to name a few off the top of my head, all do not provide from
trapping signed integer arithmetic, although most of them do provide
some way of detecting an overflow, sometime easy (like checking a flag
on x86), or sometimes rather more painfully (like on Alpha where you
basically have to do the overflow check manually).

In fact the only other machine I can think of that at least partially
implemented such a feature is the CDC-6600.

An interesting point of comparison is IEEE floating point, where that
facility *is* provided (by NaNs of various types) by every machine
that claims an even half baked implementation of the standard (which
is basically everything these days). It’s mostly ignored by the vast
majority of programmers.
Jul 17 '08 #26
th***********@gmx.at writes:
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>thomas.mer...@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?

gcc has -ftrapv -- probably only when the target can do it
efficiently.

Presumably you don't use gcc or you'd have found it in the man page ;-)

As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.

I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.
This has gone way off topic now, but on my system a signal is raised.
You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.
Can you confirm this?
No, but it is possible the flag does something quite different on your
system. It was silly of me to replay at all -- any answer will go way
off topic for c.l.c. You need to find out if the mechanism is useful
on the platforms you intend to support by posting in other groups like
comp.unix.programmer.

--
Ben.
Jul 17 '08 #27
On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?
gcc has -ftrapv -- probably only when the target can do it
efficiently.
Presumably you don't use gcc or you'd have found it in the man page ;-)
As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.
I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.

This has gone way off topic now, but on my system a signal is raised.
For floating point exceptions the SIGFPE signal is raised.
I use a handler for the SIGFPE signal which contains a
siglongjmp() to jump to the exception handler.
If a signal is raised with -ftrapv I could handle integer
overflows the same way as floating point exceptions.
So far for a non portable solution.
You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.
Can you confirm this?

No, but it is possible the flag does something quite different on your
system. *It was silly of me to replay at all -- any answer will go way
off topic for c.l.c. *You need to find out if the mechanism is useful
on the platforms you intend to support by posting in other groups like
comp.unix.programmer.
Thank you.

By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?

Which expression should be used instead of a+b,
a-b, a*b and a/b ?

Probably something like:
overflow_would_happen_add(a,b) ? raise_exception() : a+b

but how is overflow_would_happen_add() defined?

Naturally a maximum performance portable solution is best.

I am happy with every help. Thank's in advance.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 18 '08 #28
th***********@gmx.at wrote:
On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>thomas.mer...@gmx.at writes:
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?
>gcc has -ftrapv -- probably only when the target can do it
efficiently.
>Presumably you don't use gcc or you'd have found it in the man
page ;-)
As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.
I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.

This has gone way off topic now, but on my system a signal is raised.

For floating point exceptions the SIGFPE signal is raised.
I use a handler for the SIGFPE signal which contains a
siglongjmp() to jump to the exception handler.
If a signal is raised with -ftrapv I could handle integer
overflows the same way as floating point exceptions.
So far for a non portable solution.
>You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.
Can you confirm this?

No, but it is possible the flag does something quite different on
your system. *It was silly of me to replay at all -- any answer will
go way off topic for c.l.c. *You need to find out if the mechanism is
useful on the platforms you intend to support by posting in other
groups like comp.unix.programmer.

Thank you.

By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?

Which expression should be used instead of a+b,
a-b, a*b and a/b ?

Probably something like:
overflow_would_happen_add(a,b) ? raise_exception() : a+b

but how is overflow_would_happen_add() defined?

Naturally a maximum performance portable solution is best.

I am happy with every help. Thank's in advance.
Thomas, may be this code?

int add_i(int x, int y, int *sum)
{
if (((x 0 && y 0) && ((INT_MAX - x) < y)) ||
((x < 0 && y < 0) && ((INT_MIN - x) y)))
{
return 1;
}
else
{
*sum = x + y;
}
return 0;
}

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
--
Kapteyn's Star

Jul 18 '08 #29
Thomas Mertes wrote:
Today's hardware does so many things.
Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?
Your question seems appropriate for comp.lang.asm.x86
Jul 18 '08 #30
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_for_email_7kapteyns3.s...@g0m8ai2l. 9comwrote:
thomas.mer...@gmx.at wrote:
On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?
gcc has -ftrapv -- probably only when the target can do it
efficiently.
Presumably you don't use gcc or you'd have found it in the man
page ;-)
As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.
I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.
This has gone way off topic now, but on my system a signal is raised.
For floating point exceptions the SIGFPE signal is raised.
I use a handler for the SIGFPE signal which contains a
siglongjmp() to jump to the exception handler.
If a signal is raised with -ftrapv I could handle integer
overflows the same way as floating point exceptions.
So far for a non portable solution.
You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.
Can you confirm this?
No, but it is possible the flag does something quite different on
your system. *It was silly of me to replay at all -- any answer will
go way off topic for c.l.c. *You need to find out if the mechanism is
useful on the platforms you intend to support by posting in other
groups like comp.unix.programmer.
Thank you.
By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?
Which expression should be used instead of a+b,
a-b, a*b and a/b ?
Probably something like:
* overflow_would_happen_add(a,b) ? raise_exception() : a+b
but how is overflow_would_happen_add() defined?
Naturally a maximum performance portable solution is best.
I am happy with every help. Thank's in advance.

Thomas, may be this code?

int add_i(int x, int y, int *sum)
{
* * if (((x 0 && y 0) && ((INT_MAX - x) < y)) ||
* * * * ((x < 0 && y < 0) && ((INT_MIN - x) y)))
* * {
* * * * return 1;
* * }
* * else
* * {
* * * * *sum = x + y;
* * }
* * return 0;

}
Since the C code would be generated by the Seed7 compiler,
I would probably try to inline this function.
Besides this, your idea is good.

I think the number of instructions can be reduced with:

int add_i (int x, int y)
{
int sum = x + y;
if ((x 0 && y 0 && sum < 0) ||
(x < 0 && y < 0 && sum 0))) {
raise_exception();
} else {
return(sum)
}
}

I am not sure if this solution needs two's complement
representation to work.

Maybe someone has an idea to optimize this further.

Greetings Thomas Mertes

Seed7 Homepage: *http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 18 '08 #31
On Jul 18, 2:41*pm, thomas.mer...@gmx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_for_email_7kapteyns3.s...@g0m8ai2l. 9comwrote:
int add_i(int x, int y, int *sum)
...
Since the C code would be generated by the Seed7 compiler,
I would probably try to inline this function.
Besides this, your idea is good.

I think the number of instructions can be reduced with:

int add_i (int x, int y)
* {
* * int sum = x + y;
* * if ((x 0 && y 0 && sum < 0) ||
* * * * (x < 0 && y < 0 && sum 0))) {
* * * raise_exception();
* * } else {
* * * return(sum)
* * }
* }
What happened to the no-overhead requirement?

The above code uses at least 10 extra operations instead of one, a
possible extra intermediate result, and one or two jumps. And that's
for inline code. Sounds like quite an overhead to me...

Ok, this code is not yet optimised, but as it is it's likely to slow C
down to the level of interpreted code; and that's interpreted code
with the overflow check (in the form of jmp ov,somewhere) built-in!

--
Bartc
Jul 18 '08 #32
th***********@gmx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_for_email_7kapteyns3.s...@g0m8ai2l. 9comwrote:
>thomas.mer...@gmx.at wrote:
<snip>
By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?
Which expression should be used instead of a+b,
a-b, a*b and a/b ?
Probably something like:
overflow_would_happen_add(a,b) ? raise_exception() : a+b
but how is overflow_would_happen_add() defined?
Naturally a maximum performance portable solution is best.
I am happy with every help. Thank's in advance.

Thomas, may be this code?

int add_i(int x, int y, int *sum)
{
if (((x 0 && y 0) && ((INT_MAX - x) < y)) ||
((x < 0 && y < 0) && ((INT_MIN - x) y)))
{
return 1;
}
else
{
*sum = x + y;
}
return 0;

}

Since the C code would be generated by the Seed7 compiler,
I would probably try to inline this function.
Besides this, your idea is good.

I think the number of instructions can be reduced with:

int add_i (int x, int y)
{
int sum = x + y;
No. If x + y would overflow you need to detect this before such an event
in C. You above statement will send the program into undefined
behaviour upon overflow so that your further statements could do
anything. The whole *point* of doing this in pure C at considerable
computational cost is to keep it portable *and* to detect an overflow
before the event.
if ((x 0 && y 0 && sum < 0) ||
(x < 0 && y < 0 && sum 0))) {
raise_exception();
} else {
return(sum)
}
}

I am not sure if this solution needs two's complement
representation to work.
Yes.

<snip>

Jul 18 '08 #33
On Jul 18, 3:14*pm, santosh <santosh....@gmail.comwrote:
thomas.mer...@gmx.at wrote:
int add_i (int x, int y)
* {
* * int sum = x + y;

No. If x + y would overflow you need to detect this before such an event
in C. You above statement will send the program into undefined
behaviour upon overflow so that your further statements could do
anything.
Yes, but we all know that the worst thing likely to happen, is the
wrong value in sum.

After all, in many (most?) processors the overflow flag is tested /
after/ the operation, not before, which would make things difficult...

I think you have to read between the lines in the C standard if you
don't want to become completely paranoid about these things.

--
Bartc
Jul 18 '08 #34
Bart wrote:
On Jul 18, 3:14*pm, santosh <santosh....@gmail.comwrote:
>thomas.mer...@gmx.at wrote:
int add_i (int x, int y)
{
int sum = x + y;

No. If x + y would overflow you need to detect this before such an
event in C. You above statement will send the program into undefined
behaviour upon overflow so that your further statements could do
anything.

Yes, but we all know that the worst thing likely to happen, is the
wrong value in sum.
This is not a maximally portable assumption.
After all, in many (most?) processors the overflow flag is tested /
after/ the operation, not before, which would make things difficult...

I think you have to read between the lines in the C standard if you
don't want to become completely paranoid about these things.
If the OP is willing to sacrifice some portability then a least overhead
method is an inline asm statement that test the processor's overflow
flag. Does the OP anticipate his language being used on platform's
without any hardware support to detect overflow or to be compiled with
a compiler without support for inline assembler.

Jul 18 '08 #35
th***********@gmx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_for_email_7kapteyns3.s...@g0m8ai2l. 9comwrote:
>thomas.mer...@gmx.at wrote:
On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?
>gcc has -ftrapv -- probably only when the target can do it
efficiently.
>Presumably you don't use gcc or you'd have found it in the man
page ;-)
As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.
I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.
>This has gone way off topic now, but on my system a signal is
raised.
For floating point exceptions the SIGFPE signal is raised.
I use a handler for the SIGFPE signal which contains a
siglongjmp() to jump to the exception handler.
If a signal is raised with -ftrapv I could handle integer
overflows the same way as floating point exceptions.
So far for a non portable solution.
>You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible
that you can to something on the system you are using.
Can you confirm this?
>No, but it is possible the flag does something quite different on
your system. *It was silly of me to replay at all -- any answer
will go way off topic for c.l.c. *You need to find out if the
mechanism is useful on the platforms you intend to support by
posting in other groups like comp.unix.programmer.
Thank you.
By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?
Which expression should be used instead of a+b,
a-b, a*b and a/b ?
Probably something like:
overflow_would_happen_add(a,b) ? raise_exception() : a+b
but how is overflow_would_happen_add() defined?
Naturally a maximum performance portable solution is best.
I am happy with every help. Thank's in advance.

Thomas, may be this code?

int add_i(int x, int y, int *sum)
{
if (((x 0 && y 0) && ((INT_MAX - x) < y)) ||
((x < 0 && y < 0) && ((INT_MIN - x) y)))
{
return 1;
}
else
{
*sum = x + y;
}
return 0;

}

Since the C code would be generated by the Seed7 compiler,
I would probably try to inline this function.
Besides this, your idea is good.

I think the number of instructions can be reduced with:

int add_i (int x, int y)
{
int sum = x + y;
if ((x 0 && y 0 && sum < 0) ||
(x < 0 && y < 0 && sum 0))) {
raise_exception();
} else {
return(sum)
}
}

I am not sure if this solution needs two's complement
representation to work.
Im sorry Thomas, i don't really know what two's complement is. I
understand that its a way to represent signed numbers but i dont know
how is exacty works. in fact i only found about INT_MAX and INT_MIN
just ysterday.
--
Kapteyn's Star

Jul 18 '08 #36
Kapteyn's Star wrote:

Please snip material which either does not contextually contribute to
your article (both to your reply and to the quoted text), or are is
supposed to be snipped when replying like signatures (unless you happen
to specifically comment on them).
Im sorry Thomas, i don't really know what two's complement is. I
understand that its a way to represent signed numbers but i dont know
how is exacty works. in fact i only found about INT_MAX and INT_MIN
just ysterday.
Maybe these links will help.

<http://mathforum.org/library/drmath/sets/select/dm_twos_complement.html>
<http://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html>
<http://academic.evergreen.edu/projects/biophysics/technotes/program/2s_comp.htm>

Jul 18 '08 #37
On 18 Jul., 16:12, Bart <b...@freeuk.comwrote:
On Jul 18, 2:41*pm, thomas.mer...@gmx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_for_email_7kapteyns3.s...@g0m8ai2l. 9comwrote:
int add_i(int x, int y, int *sum)

...
Since the C code would be generated by the Seed7 compiler,
I would probably try to inline this function.
Besides this, your idea is good.
I think the number of instructions can be reduced with:
int add_i (int x, int y)
* {
* * int sum = x + y;
* * if ((x 0 && y 0 && sum < 0) ||
* * * * (x < 0 && y < 0 && sum 0))) {
* * * raise_exception();
* * } else {
* * * return(sum)
* * }
* }

What happened to the no-overhead requirement?
Nothing. It is still the preferred solution.
I just want to explore all possibilities.
The above code uses at least 10 extra operations instead of one, a
possible extra intermediate result, and one or two jumps. And that's
for inline code. Sounds like quite an overhead to me...
Yes, this is quite an overhead. Such an overhead should not
be forced on the users by default.
Ok, this code is not yet optimised, but as it is it's likely to slow C
down to the level of interpreted code; and that's interpreted code
with the overflow check (in the form of jmp ov,somewhere) built-in!
If I decide to implement integer overflow detection
for Seed7 there will be several alternate implementations:

- Use some (now unknown) feature to have zero overhead.
- Maybe the next C standard will contain something.
- Use the -ftrapv feature of gcc.
- Use some other compiler feature like accessing the
overflow flag.
- Maybe a solution with inline assembler.
- Use some semi portable solution (which may assume a
two's complement representation).
- A 100% portable solution which assumes that the computer
explodes if an integer overflow occurs.

Which of this solutions is used, would be decided with
feature tests. Such feature tests can be done when
installing Seed7 (The Seed7 interpreter and its runtime
library are delivered as C source).
When the Seed7 compiler generates C it can use the results
of this feature tests to generate the C program.

Currently the Seed7 compiler already uses some feature
tests to conditionally generate code.
It contains code like

if not USE_SIGSETJMP then
writeln(c_prog, "signal(SIGFPE, handle_fpe_signal);");
end if;

which generates code conditionally.

It is my intention to make it possible to turn the
integer overflow check on and off. Maybe it makes sense
when every program contains some pragma to decide if it
wants an integer overflow check.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 18 '08 #38
th***********@gmx.at writes:
I think the number of instructions can be reduced with:

int add_i (int x, int y)
{
int sum = x + y;
if ((x 0 && y 0 && sum < 0) ||
(x < 0 && y < 0 && sum 0))) {
raise_exception();
} else {
return(sum)
}
}
This is not portable because you don't know what the x + y will have
done. Of course, you may not be aiming for portable output from your
translator...

--
Ben.
Jul 18 '08 #39
santosh wrote:
Kapteyn's Star wrote:

Please snip material which either does not contextually contribute to
your article (both to your reply and to the quoted text), or are is
supposed to be snipped when replying like signatures (unless you
happen to specifically comment on them).
OK.
>Im sorry Thomas, i don't really know what two's complement is. I
understand that its a way to represent signed numbers but i dont know
how is exacty works. in fact i only found about INT_MAX and INT_MIN
just ysterday.

Maybe these links will help.

<http://mathforum.org/library/drmath/sets/select/dm_twos_complement.html>
<http://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html>
<http://academic.evergreen.edu/projects/biophysics/technotes/program/2s_comp.htm>

All are very intersting. Thanks very much.

--
Kapteyn's Star

Jul 18 '08 #40
On 18 Jul., 19:04, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
thomas.mer...@gmx.at writes:
I think the number of instructions can be reduced with:
int add_i (int x, int y)
* {
* * int sum = x + y;
* * if ((x 0 && y 0 && sum < 0) ||
* * * * (x < 0 && y < 0 && sum 0))) {
* * * raise_exception();
* * } else {
* * * return(sum)
* * }
* }

This is not portable because you don't know what the x + y will have
done. *Of course, you may not be aiming for portable output from your
translator...
Exactly. The output of the Seed7 to C translator will
probably not be portable.

The Seed7 compiler (which compiles to C) aims to compile
portable Seed7 programs. Perhaps this goal can be reached
by compiling a Seed7 program to different C programs.
This depends on the C compiler and the operating system.
That way the C program generated by the Seed7 compiler
is not portable as it is tailored to one C compiler and
one operating system. At the same time the associated
Seed7 program can be 100% portable.

BTW: The call of the C compiler is encapsulated in the
Seed7 compiler. This makes sense, since the generated
C program would not get an award for pretty code.

To come back to the topic of catching integer overflow.
I am searching for all solutions to the problem in
the range:

more portable <------- more performance

Solutions which work only for some machines/compilers
are interesting if they provide better performance than
a more portable version.

What algorithms for overflow recognizing integer
operations do you suggest?

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Jul 18 '08 #41
On Jul 18, 5:28*pm, thomas.mer...@gmx.at wrote:
On 18 Jul., 16:12, Bart <b...@freeuk.comwrote:
What happened to the no-overhead requirement?

Nothing. It is still the preferred solution.
I just want to explore all possibilities.
The above code uses at least 10 extra operations instead of one, a
possible extra intermediate result, and one or two jumps. And that's
for inline code. Sounds like quite an overhead to me...

Yes, this is quite an overhead. Such an overhead should not
be forced on the users by default.
Actually it is not as slow as I thought. A quick test gave a 3x
slowdown.
If I decide to implement integer overflow detection
for Seed7 there will be several alternate implementations:

*- Use some (now unknown) feature to have zero overhead.
*- Maybe the next C standard will contain something.
That's a long wait. Even longer to get something implemented.
*- Use the -ftrapv feature of gcc.
*- Use some other compiler feature like accessing the
* *overflow flag.
*- Maybe a solution with inline assembler.
For little overhead I think you can't beat a "jmp ov,traphandler" type
of inline asm, tailored for each target.
*- Use some semi portable solution (which may assume a
* *two's complement representation).
*- A 100% portable solution which assumes that the computer
* *explodes if an integer overflow occurs.
Trust me the computer will not explode. Not unless you wired the
overflow flag to a detonator and some dynamite.
Which of this solutions is used, would be decided with
feature tests.
Actually I've just added this integer overflow test to one of my
interpreters. I used the "jo traphandler" solution for x86. It
resulted in a slowdown of some 1% for code which did nothing but
integer adds. I was only testing but I think now I'll keep it in! It
might pick up extra bugs.

Thanks for the idea.

--
Bartc
Jul 18 '08 #42
On 17 Jul, 10:30, "Bartc" <b...@freeuk.comwrote:
"Keith Thompson" <ks...@mib.orgwrote in message

news:ln************@nuthaus.mib.org...
"Bartc" <b...@freeuk.comwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]
You'd rather have wrong answers quickly?

Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

But if there is a hardware trap (like divide by zero) that didn't slow
things down, then that's fine, provided the overflow was a genuine error. I
can see that being difficult to implement however, unless you also have
separate arithmetic instructions for signed and unsigned values.
http://en.wikipedia.org/wiki/Ariane_5_Flight_501

--
Nick Keighley
Jul 21 '08 #43

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.