Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!skipper!rando
From: rando@skipper.dfrf.nasa.gov (Randy Brumbaugh)
Newsgroups: comp.sys.transputer
Subject: Re: 3L Compilers & Error Flag
Keywords: Error 3L C FORTRAN
Message-ID: <645@skipper.dfrf.nasa.gov>
Date: 20 Sep 90 19:29:39 GMT
References: <642@skipper.dfrf.nasa.gov> <rob.653734866@dutncp8>
Organization: NASA Ames-Dryden FRF, Edwards, CA
Lines: 47

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