🚀 go-pugleaf

In article <DL2CFs.FG0@harlequin.co.uk>, daveb@harlqn.co.uk (Dave Berry) writes:
|> baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
|> >Daniel Wood (dwood@informix.com) wrote:
|> >: Do any machines exist which actually explode when you add two number together
|> >: such that the result would exceed MAXINT? :-)  Get practical!
|> >
|> >VAXes
|> >If you set the apropriate bit in the process status word then integer overflow
|> >causes a trap.
|> 
|> The SPARC and MIPS processors also have integer instructions that trap on
|> overflow.

Not to say the IBM 370 and numerous others.  In any case, it isn't
difficult to compile in reasonably efficient software checks.  But,
as others have pointed out, that isn't the issue.

Most compilers (whether C, Fortran or other) do not generate code
that will trigger the trap.  On the IBM 370, several of them did
so more by accident than design, and so would trap on addition but
not multiplication!  Even those that did it 'properly' often left
it out of conversions and I/O.

Some systems have a process flag that triggers whether integer
overflow causes an exception or not.  Write a bit of assembler
that flips that bit and trying running a few programs - you will
probably find that valid array indexing fails or the run-time
system dies horribly (e.g. in I/O conversion).

I would like this feature very much, but I don't expect to see it
come back into most Fortran systems, let alone C ones!  But the
standard definitely allows it (for signed values and many or most
conversions).


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679