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]
>
- Navigate by Date:
- Prev:
EPICS support for LAN/GPIB gateway HP E2050A Benjamin Franksen
- Next:
Doc on stepperMotor record Benjamin Franksen
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
EPICS support for LAN/GPIB gateway HP E2050A Benjamin Franksen
- Next:
Doc on stepperMotor record Benjamin Franksen
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|