EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: FW: GCC generates floating point code on its own for PPC.
From: [email protected] (Jeff Hill)
To: "EPICS-tech-talk" <[email protected]>
Date: Wed, 4 Aug 1999 14:26:30 -0600
All,

This may be interesting to persons who are using the PPC
architecture.

Jeff

> -----Original Message-----
> From: the vxWorks Users Group Exploder [mailto:[email protected]]
> Sent: Wednesday, August 04, 1999 7:57 AM
> To: [email protected]
> Subject: RE: GCC generates floating point code on its own for PPC.
>
>
> Submitted-by owner-vxwexplo-process  Wed Aug  4 06:57:13 1999
> Submitted-by: "Mike Anderson" <[email protected]>
>
> VxWorks Greetings!
>
> >
> > Could you please explain why you feel this is context corruption?
> >  I'm trying
> > to get a clearer picture as to why this optimization should not
> > be allowed.
> > VxWorks saves/restores the FPU registers upon entry/exit of a
> > task with FPU
> > support.  The only possibility is for the mentioned task to not have FPU
> > support and it gets interrupted between the load/store.  Is
> that what you
> > mean?  As Bill Cox states, this is a valid optimization (by all
> > appearances).
> > The 603 has an FPU and FPU support is enabled in the kernel.
> >
>
>   I believe that the issue here is that gcc/egcs is trying
> to optimize move instructions by utilizing the FPU registers.
> This is no problem in the case of floating-point enabled tasks,
> but it plays hell when this thing happens in an ISR without
> your knowledge.
>
> For example, you believe that everything is OK with your
> FPU because you think that all of your tasks are either not
> using floating point or are spawned as floating point safe.
> Unfortunately, you missed the hidden floating point that
> got generated in that innocent multiply *2 instruction used
> by one of your jr programmers who didn't know better.  Then
> wham!  One of your ISRs gets invoked and clobbers your FPU
> context during the multiply operation and now the results
> of the multiply (remember the buffer index operation your
> programmer needed that multiply for in the first place? ;-)
> causes the pointer to go off into la-la land.
>
>   If you're lucky, it dies immediately.  If not, it may run
> for a while before it dies while overwritting key program/data
> areas.
>
>   The other issue is what happens if your task happens to be
> performing one of these very same move operations using the
> FPU registers when an ISR happens.  Even though your task wasn't
> using the FPU explicitly, it really was -- as far as the compiler
> was concerned.  Now, the data in your task's operation is
> corrupted and you are none the wiser.
>
>   This says that if you *need* to use hardware floating point
> (i.e., not enable -msoft-float on the PPC using the GNU
> compiler at least), you might want to seriously consider
> saving and restoring the FPU context as you enter and leave
> your ISRs.  Of course, your have to hope that WRS did the same
> thing for their device ISRs as well.
>
>   BTW, this is not the first time this kind of thing has come
> up.  Many of us old-timers remember the Sun 3 CC compiler generating
> extraneous floating point code for our 68Ks.  There we simply
> had to bump up the optimization level for the code to eliminate
> the problem.
>
>   This problem with the PPC is much more insidious because
> it's pervasive throughout the code and only visible if
> you look at the assembly language output from the compiler.
> So, all of you folks who only use C-source debuggers without
> going to the mixed assembly mode, probably get what you deserve ;-).
>
> Just my $.02,
>
> Mike Anderson
> -----------------------------------------------------------------
> Michael E. Anderson                | Integrated Chipware
> Chief Scientist                    | 1861 Wiehle Ave. #300
>                                    | Reston, VA 20190
> [email protected]                  | (703) 736-3504
> www.chipware.com    (888)430-CHIP  | (703) 736-3556 FAX
> -----------------------------------------------------------------
>  "Software development is like making a baby.
>   You can't make a baby in one month by impregnating nine women.
>   Some things just take time..."
>
>
> **********
>
>     This is a user group mailing list for vxWorks related topics
>     Mail articles to [email protected] for 'explosion'
>       Include the word VxWorks or Tornado to penetrate SPAM filters
>       edit off the trailer to avoid bounce filters
>     Send subscription requests & comments to [email protected]
>



Navigate by Date:
Prev: Release of ipac V2-1 Andrew Johnson
Next: FW: MVME162 Bug in system clock Jeff Hill
Index: 1994  1995  1996  1997  1998  <19992000  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: Release of ipac V2-1 Andrew Johnson
Next: FW: MVME162 Bug in system clock Jeff Hill
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·