🚀 go-pugleaf

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.