Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 29 May 1997 08:31:18 -0600

overheard on the vxWorks mail list....

> > Submitted-by [email protected]  Wed May 28 11:04:52 1997
> > Submitted-by: Andrew Pearce <[email protected]>
> > 
> > Hi,
> >      we have noticed that floating point operations on 68040 platforms 
> > can take widely different times to execute, depending on the value of
> > the numbers being used. Below are two similar functions that illustrate
> > the behavior.  Each function multiplies two floats, but testFMul2
> > causes a floating point underflow to occur when the multiply is
> > performed.
> > Using timexN from the vxWorks shell, we see that testFMul1 takes 1 usec
> > to execute, but testFMul2 takes 26 usec to execute. The Underflow
(UNFL)
> > and Inexact (INEX) flags are set true in the Floating Point Status
> > Register.
> > 
> > Reading the chapter on the 68040 Floating Point Unit suggests that 
> > the FPU is performing exception processing in an attempt to return
> > the most precise value that it can, given that an underflow has
> > occurred. This exception processing is internal to the FPU 
> > and does not involve the 68040 because the exception enable bits
> > are set false by vxWorks.
> > 
> > Does anyone have experience with this problem and can tell me
> > if my reasoning is correct here? I am surprised that the 
> > exception procssing seems to takes 26 times longer than the
> > multiply!
> 
> I think you are correct here.
> 
> > 
> > One issue for real-time systems is that the 68040 FPU conforms
> > to the IEEE 754 standard. I imagine that the goal of the standard
> > is numerical exactness so that you get the same answer regardless
> > of the platform in use. It probably doesn't say much about 
> > deterministic behavior.
> > 
> > We started looking at this problem because our control system
> > would normally take 10% of the CPU, but occasionally would 
> > jump up to take over 30% of the CPU.
> > 
> 
> The problem is that the 68040`s floating point unit does the FP
> denormalization with an exception.  This is what causes your execution
> time differences.  Whenever the system needs to denormalize a small
> number, then a trap is taken.  We "solved" this problem in some of our
> systems by flushing a very small number to 0 when we see it.  You can
> see this effect if you have a control system that can drive an error
> term to 0, and there is no noise in the system, like in a simulation
> of a dynamic system.  I investigated this with Motorola, and they
> said there was no solution.  I think you could hack the 040 math
> library code (in assembly, naturally!) to flush to 0 when an
> underflow occurs.  As you point out, this causes the implementation to
> violate the IEEE 754 standard.
> 
> Personally, I think Motorola erred in crippling the 040`s FP unit by
> moving so many instructions into firmware.
> 
> -- 
> John Ford
> National Radio Astronomy Observatory
> Green Bank, WV 24944-0002
> [email protected]
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System