detecting integer overflow

[Mark McIntyre]

Alpha allows (optional) traps on integer add/subtract/multiply
overflows, but has no overflow flag. MIPS allows traps on adds and
subtracts (but no flag). ARM has an (optional) overflow flag, but it's
not set by the multiply instructions. S/360 (zSeries) and PPC can set
an overflow condition code on adds and subtracts, or take a trap, but
not on multiplications. PA-RISC can trap on addition and subtraction,
and can trap on multiplication with a special multi-instruction
sequence. SPARC has the traditional condition code for add and
subtract, but not for multiply. IPF and PIC provide niether traps or
flags for integer arithmetic.

Most vector ISA extensions have very limited, if any, support for
integer overflows during vector operations.

I'm guessing you're surprised?

I'm not. Neither am I surprised that Jacob posted what he did - he
apparently has very little experience outside the wintel world, but
doesn't seem to realise this.

 

[jacob navia]

(e-mail address removed) a écrit :

That's a rather stronger statement than is justified.

I'm guessing you're surprised?

Yes, how many brain dead machines...

In any case this is OK, people using those machines can always do

#pragma STDC integeroverflow(off)

or the compiler can state in the documentation that overflow catching
does not work.

What is important is that we stop levelling by the lowest possible
common feature, and try to improve the language definition allowing for
machines that do not have the feature to run.

If the C standard allows for a very fine definition of the floating
point flags environment, I do not see why integers would not be allowed
the same properties!

What happens in the FPU that has no flags???

Well, the compiler can issue bogus functions or return always
zero, etc. Nonetheless the FPU flags are in the standard.
jacob

 

[jacob navia]

Randy Howard a écrit :

jacob navia wrote



Here it comes, wait for it...




This is going to hurt.

Well, apparently it hurted so much that you forgot
the rest of the message ???



jacob

 

[jacob navia]

Mark McIntyre a écrit :

I'm not. Neither am I surprised that Jacob posted what he did - he
apparently has very little experience outside the wintel world, but
doesn't seem to realise this.

Maybe, I have done in the last year only some DSP assembly,
and my 68000 experience is very rusty.

Who cares? I am not "the guru", and when I stand corrected
I feel no shame to acknowledge that I was wrong.

Whats the point in discussing if you want to be always right?

jacob

 

[Randy Howard]

jacob navia wrote

Randy Howard a écrit :

Well, apparently it hurted so much that you forgot
the rest of the message ???

What's a "hurted"?

At any rate, the other responses to this thread have already
demonstrated the point sufficiently. Are you now "surprised"?

 

[RSoIsCaIrLiIoA]

As many posters have replied here, you *can* test for overflow
yourself. What bothers me, is that the language does not enforce this
even if it is a break of the standard, as Jack Klein has noted in
this same thread.

The lcc-win32 compiler tests for overflow with a command line
switch. This wasn't very difficult to do, and the impact
in the run time is minimal, in any case not even measurable
for a normal application in a PC environment.

OF COURSE there are other environments where each microsecond counts
and where the quality of the results doesn't matter so much...

For *those* environments the language stdandard *could* make an
exception, for instance

#pragma STDC intergeroverflow(off)

or similar.

But in a normal case, integer overflow is a serious error,
an error that is very difficult to catch if not done at the
compiler level. You think you could have an overflow *here* or
*there* but actually you got an overflow in a completely unexpected
place!


The code generated is not specially clever. Here is the code for this
program:
int main(void)
{
int a = 0x7fffffff,b=0x7fffffff;
int c = a*b;
}

For the relevant line we get this:
; 4 int c = a*b;
.line 4
movl -4(%ebp),%edi ; put a in edi
imull -8(%ebp),%edi ; multiply by b
jno _$L2 ; if no overflow continue at L2
pusha ; OVERFLOW save all regs
pushl $4 ; push the line number
pushl $main__labelname ; push the name of the function
call __overflow ; call the exception handler
addl $8,%esp ; restore stack
popa ; restore all regs
_$L2: go on

The overflow handler is prototyped as:

void __overflow(char *function name, int line);

i like that. I like to imagine too ...
it will be more useful if the programmer can set in the compiler, the
errors that want to see in the "runtime programme" (e.g. overflow
errors, memory leak, out of bound in writing array etc)
and there is reserved memory (e.g. 100kb) *structured like in a queue*
where the "handler " write the error that find and where the error is.

Then, at the end of programme, the memory is written down in a file:
error_programm_name.txt

So i read error_programm_name.txt for see if all is ok
while all you don't know what is "going wrong" and "where"

Other mechanisms could be considered, and the generated code *could*
be better. I have found that in PC environnments, where lcc-win32 runs,
this is absolutely not measurable for normal applications...

jacob

Buon Natale a tutti