At 09:58 11.12.2006 +0000, Andrew Haley wrote: >Fabian Cenedese writes: > > At 14:33 07.12.2006 +0100, Fabian Cenedese wrote: > > >Hi > > > > > >Is there a flag to tell gcc NOT to use float assembler commands > > >for 64bit data? We have problems that the generated code contains > > >float commands while the target (partially) has no float support. > > > > > >The float commands are simply used for moving 64 bit of data around. > > >That may be faster than 2x32 but not working here. I'm interested in > > >workarounds for various gcc versions (2.95, 3.4, 4.x). > > > > Doesn't anybody know a way around this? Or has the same problem? > >I guess we're having difficulty understanding why -msoft-float is not >appropriate for you. It seems to me obviously the right thing to do >with a target (partially) without float support. I quote here from the old mail: -------------------- In our kernel I can create tasks with floating point enabled or disabled. If I don't need floating numbers in a task I disable them to improve task switches (much faster because the kernel doesn't have to save/restore the 32 floating point registers of the PPC603). So my problem is if I work with 64 Bit integers or stuctures in a task with floating support disabled this task stops with a floating point exception. -------------------- PPC603 of course has a FPU and we make good use of it. But there are some tasks that don't need float/double, so we disable the floating point support on those tasks (see above). But as the FPU registers are not saved on a task switch it can happen that they get destroyed if a task switch happens right between the lfd/stfd (and we sure had that). Generally using -msoft-float would change all float calculations and therefore make the whole program slower. That's not possible on axis controllers that are already at the limit of the CPU. And there are also (inline) functions that get used from both floating point enabled and disabled tasks. The best thing for us would be some kind of -msoft-float-ll which would only affect the (mis)use of the FPU for moving 64bit long longs around but leave the real float calculations intact. The second best may be a pragma or attribute for explicit code sections. If there is no such thing we would also change the gcc code itself if this code generation is in a central place. Of course we would prefer to use the vanilla gcc. Moving all those critical code parts into one file that can be compiled with -msoft-float may be doable for our OS (thought not really usable as we enable/disable functionality by including/excluding files from linking). But for our (not always C++-savy) customers it can't be the solution. "Your self-written code crashes? Just use -msoft-float. It will be much slower but work." That's why I'm looking for a general solution. Thanks bye Fabi
