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
<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:
Release of ipac V2-1 Andrew Johnson
- Next:
FW: MVME162 Bug in system clock Jeff Hill
- 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
|