Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs C for computations
Message-ID: <3385@lanl.gov>
Date: 9 Sep 88 20:45:40 GMT
References: <373@quintus.UUCP>
Organization: Los Alamos National Laboratory
Lines: 42

From article <373@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe):
> 
> We could have something like
> 	CALL HANDLE(exception, handler, oldhandler, ierror)
> where ierror would be set to a suitable value if the implementation was
> not able to catch that kind of error.  For example,
> 	CALL HANDLE('OVERFLOW', MYOVHD, OLDHD, IERROR)
> 	IF (IERROR .NE. 0) STOP 'CAN''T CATCH OVERFLOWS'

How does this suggestion differ from the supplimentary standard idea I
proposed in my last article (which you criticized the first part and appear
to have ignored the rest)?  My point is that it shouldn't be part of the 
language definition for two reasons: 1) it means that any machine/system
that can't support it won't be able to have a standard conforming environ-
ment; 2) if it's part of the language definition, different languages
will undoubtedly define the mechanism in different - mutually incompatible
ways.  Indeed, something like what you suggest _is_ available on all the
large-scale Fortran environments I've ever worked on.  The problem isn't
that Fortran doesn't have it and C does (C doesn't - the C library sometimes
does - the ANSI C standard _may_ require it), the problem is that there
is no language-independent standard for this functionality.

> Good heavens, if we were to accept the "some machines don't want to do it"
> argument, we wouldn't have floating-point arithmetic, and then where would
> Fortran be?

Some machines _don't_ have floating-point!  Neither Fortran nor C can 
run on such machines without simulating.  Interrupts can't even be 
simulated on machines/systems that don't provide such access.  (I've
talked with hardware designers and it's not as easy as you seem to 
think.  Consider overflow for example.  You want to intercept the
exception and do something to fix-up the result.  On a vector machine,
how do you tell which vector element needs fixing?  All the hardware
mechanisms to give you that information are either slow of prohibitively
costly or both.  The problem may even be worse for parallel archetectures
where you may not even know which CPU genereated the exception!  It's
all very simple on a primitive machine like a VAX (but even VAXen are
pipelined these days) - on faster machines, the best solution may really
be to halt the offending process with a message and not to provide
run-time exception handling to the user.)

J. Giles
Los Alamos