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  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 
<== Date ==> <== Thread ==>

Subject: FW: GCC generates floating point code on its own for PPC.
From: johill@lanl.gov (Jeff Hill)
To: "EPICS-tech-talk" <tech-talk@aps.anl.gov>
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:vxwexplo@lbl.gov]
> Sent: Wednesday, August 04, 1999 7:57 AM
> To: vxworks_users@csg.lbl.gov
> 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" <mike@chipware.com>
>
> 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
> mike@chipware.com                  | (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 vxwexplo@lbl.gov 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 vxwexplo-request@lbl.gov
>



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 
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 
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 ·