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
42  7033 
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_ for_email_7kapt eyns3.s...@g0m8 ai2l.9comwrote:
thomas.mer...@g mx.at wrote:
On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb .me.ukwrote:
thomas.mer...@g mx.at writes:
On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb .me.ukwrote:
thomas.mer...@g mx.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.progr ammer.
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.
On Jul 18, 2:41*pm, thomas.mer...@g mx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_ for_email_7kapt eyns3.s...@g0m8 ai2l.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 th***********@g mx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_ for_email_7kapt eyns3.s...@g0m8 ai2l.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>
On Jul 18, 3:14*pm, santosh <santosh....@gm ail.comwrote:
thomas.mer...@g mx.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
Bart wrote:
On Jul 18, 3:14*pm, santosh <santosh....@gm ail.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. th***********@g mx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_ for_email_7kapt eyns3.s...@g0m8 ai2l.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.progr ammer.
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
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_complem ent.html>
<http://www.cs.cornell. edu/~tomf/notes/cps104/twoscomp.html>
<http://academic.evergr een.edu/projects/biophysics/technotes/program/2s_comp.htm>
On 18 Jul., 16:12, Bart <b...@freeuk.co mwrote:
On Jul 18, 2:41*pm, thomas.mer...@g mx.at wrote:
On 18 Jul., 14:23, Kapteyn's Star
<remove_digits_ for_email_7kapt eyns3.s...@g0m8 ai2l.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(SIG FPE, handle_fpe_sign al);");
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. th***********@g mx.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.
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_complem ent.html>
<http://www.cs.cornell. edu/~tomf/notes/cps104/twoscomp.html>
<http://academic.evergr een.edu/projects/biophysics/technotes/program/2s_comp.htm>
All are very intersting. Thanks very much.
--
Kapteyn's Star This thread has been closed and replies have been disabled. Please start a new discussion. |
