Path: utzoo!attcan!uunet!mcsun!hp4nl!dutrun!dutncp8!rob From: rob@dutncp8.tudelft.nl (Rob Kurver) Newsgroups: comp.sys.transputer Subject: Re: 3L Compilers & Error Flag Keywords: Error 3L C FORTRAN Message-ID: Date: 19 Sep 90 09:01:06 GMT References: <642@skipper.dfrf.nasa.gov> Sender: news@dutrun.UUCP Lines: 54 Organisation: Delft University of Technology, The Netherlands In <642@skipper.dfrf.nasa.gov> rando@skipper.dfrf.nasa.gov (Randy Brumbaugh) writes: >The 3L C and 3L FORTRAN compiler manuals state that >code generated by these compilers may cause the error >flag to be set, in the interest of efficiency. This >has led to some discussion around here, and we have several >questions we can't answer. Anybody else know anything >about this? >1) Why do they need to set the error flag? I don't > understand how this improves efficiency. Furthermore, > when I look in the Transputer Reference Manual and > see the instructions which cause this flag to be set > (divide by zero, overflow, out-of-bounds, etc), I > wonder - aren't these errors things that shouldn't > happen. Aren't they things that should cause an > error? The error flag doesn't add anything useful to C or FORTRAN compiled code - it flags on the wrong things for these languages (e.g. integer overflow is perfectly well defined in C). Supporting it would not add any functionality and only slow code down. The position taken by most (all?) non-OCCAM compiler writers has been to ignore the flag. >2) What conditions cause this to be set? > Is it certain operations, or a sequence, or a complex > data structure reference or what? The flag is set by the transputer hardware after certain instructions, depending on the operands. When it gets set, it may stop the processor (if the HaltOnError flag is set), or not. If not stopped, the flag stays set until manually reset (sticky). >3) Is there any way to program and be sure that the > error flag won't be set by normal operation, so that > it may be used for debugging? I'm afraid not. Some compilers may have an option to generate 'clean' (slow, errorflag-testable) code, but I don't know of any. Supporting the error flag is just too expensive... What's wrong with using a symbolic debugger? >4) How are other people debugging complex, multi-xputer > systems, without using the Error siganl? It seems > like the Error signal is about the only way to detect > software faults easily and simply. Really? -- Rob Kurver rob@dutncp8.tudelft.nl Computational Physics Group rob@pact.nl Faculty of Applied Physics, Delft University of Technology "His super power is to turn into a scotch terrier."