rando@skipper.dfrf.nasa.gov (Randy Brumbaugh) (09/19/90)
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? 2) What conditions cause this to be set? Is it certain operations, or a sequence, or a complex data structure reference or what? 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? 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. Any answers, comments, or suggestions are appreciated. Post or e-mail Thanks, Randy Brumbaugh rando@skipper.dfrf.nasa.gov
rob@dutncp8.tudelft.nl (Rob Kurver) (09/19/90)
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."
rando@skipper.dfrf.nasa.gov (Randy Brumbaugh) (09/21/90)
This is a followup to my original posting . . . The first response I got (from Rob Kurver) indicates either that he is not used to working with transputer hardware, or that the questions were unclear. Anyway, I'll try to clarify. The original questions concerned the habit most compilers seem to have of setting the Error flag during normal operation on the transputer. This flag is set when bad things happen, like divide by zero or overflow. These are things that I would like to know about, when my software does them. In general I would write software which I believe avoids these traits, and if one of them happens, it IS an error, and it IS useful to know it has happened -- in fact, it may be closer to critical than useful. Now, a clarification - I am talking about the hardware Error line, in embedded transputer systems. This line, used with Halt and Analyze, may provide some clues to aid in detecting and correcting faults, especially software. The transputer doesn't have any sort of error traps, just this. And the compilers break this tool for me. Must be a good reason -- What is it? Speed? What exactly is it that causes the compiler to generate code which sets this flag? And why is it so much more efficient? And is there any way to make the code "clean" - not generate the Error for normal operation? I am familiar both with C programming and the transputer instruction set, and I can see no obvious reason for a C compiler to produce "dirty" code. There should be an option in any case. Given the trade-off between speed and reliability / testability, the choice is easy. It may be different for another application, but not embedded aircraft systems. The suggestion was made to use a symbolic debugger. I can only hope that it was a joke; we all got a chuckle out of it. After all, the debugger adds overhead, takes up space, and slows things down. Not so good, especially for a limited memory, real-time system. Anyway, wasn't speed the object of all this smaller and faster code? And of course, a debugger is only useful for development. How do you debug a multi-transputer system application? I still believe the Error signal is about the only way to detect software faults simply. Randy Brumbaugh rando@skipper.dfrf.nasa.gov
rob@dutncp8.tudelft.nl (Rob Kurver) (09/23/90)
In <645@skipper.dfrf.nasa.gov> rando@skipper.dfrf.nasa.gov (Randy Brumbaugh) writes: >This is a followup to my original posting . . . >The first response I got (from Rob Kurver) indicates either that >he is not used to working with transputer hardware, or that the >questions were unclear. Anyway, I'll try to clarify. I guess I missed the point of your questions - let me try again. > ... >Now, a clarification - I am talking about the hardware Error line, >in embedded transputer systems. This line, used with Halt and >Analyze, may provide some clues to aid in detecting and correcting >faults, especially software. The transputer doesn't have any sort >of error traps, just this. And the compilers break this tool for >me. Must be a good reason -- What is it? Speed. >Speed? What exactly is it that causes the compiler to generate >code which sets this flag? And why is it so much more efficient? >And is there any way to make the code "clean" - not generate the >Error for normal operation? I am familiar both with C programming >and the transputer instruction set, and I can see no obvious reason >for a C compiler to produce "dirty" code. Dirty code is faster. If you don't care about the error flag, you can do the following optimizations: use adc for unsigned objects, and use prod for all multiplications. My company's transputer C compiler (expected to be released Q01/91) has an option allowing you to choose between dirty and clean code (%). To give you an idea: compiling the dhrystone v2.0 benchmark clean slows it down by a little over 10%. I agree an option is useful (that's why we have it). It leaves you with the problem of the runtime though: should it be compiled clean and slow, or dirty and fast? Or do you want two versions? Maybe I'm missing the point again, and you only wanna know what 3L does, and how you can be smarter than the compiler. Sorry if this is the case. Oh well... Maybe I should just go home now... :-) Cheers. - Rob rob@pact.nl (%): If you're interested in being a beta-test site, mail to me at rob@pact.nl. -- Rob Kurver rob@dutncp8.tudelft.nl Computational Physics Group rob@pact.nl Faculty of Applied Physics, Delft University of Technology When you're not looking at it, this fortune is written in FORTRAN.