Re: [Caml-list] int_of_string bug

[skaller <skaller@users.sourceforge.net>]

On Fri, 2007-03-30 at 10:59 +0200, Andreas Rossberg wrote:
> skaller wrote:
> >>
> >>> That's a problem too, but there is at least a defensible reason for
> >>> that, which is that it is expensive to get integer overflow to throw
> >>> an exception.
> >> i386 and amd64 have hardware support for that, so it's not very
> >> expensive.  There are pretty short RISC sequences for the checks, too.
> >>
> >> MLton uses the i386 hardware support, and I think you can disable the
> >> checks, so measuring the overhead shouldn't be too hard.
> > 
> > But there is a difference you may have missed: Ocaml integers
> > are 31 or 63 bits, not 32 or 64 bits. 
> 
> But it uses the most significant 31/63 bits for ints, so that becomes a 
> non-issue. ;-)

For addition maybe, certainly not for multiplication: one of the
operands has to be shifted right 1 place.

But it depends on the code generator internal details. You could
always shift BOTH operands, do the register calculation, then
shift back .. in which case you'd lose overflow detection.
The problem is you cannot use the carry bit after the shift back
because the bit will definitely be set if the result is negative.

>From what I've seen Ocaml actually uses tricks which also might
defeat detection, for example I've seen some use of LEA
(load effective address) with the scale by 2 option to 
load and shift one bit in a single instruction.

Processors are quirky about flag bits .. some set sign bit
on loading and others don't, etc, so it could be quite messy.
This is why C doesn't specify what happens on overflow:
it would compromise performance on some processors.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net