PowerPC BSP mvme5500 and hardfloat.

[Joel Sherrill]

On Dec 12, 2013 6:25 AM, Matt Wette <mwette at alumni.caltech.edu> wrote:
>
> But if you don't use FP in ISR you still need to compile the ISR with -fsoft-float because the compiler may dirty the FP registers otherwise.
> For example: a = b; where a, b are struct timespec may be implemented in FP registers.

Agreed and that is what I was trying to.point out. If FPU usage by the compiler is implicit and surprising, then you have to be cautious in isr and driver code.

The larger issue is that if this setting is in the BSP's .cfg file, it impacts all user, rtems and bsp code. If desirable, it should be added as an extra addition in Makefile.am for the BSP so its impact is limited to the bsp.
>
> On Dec 11, 2013, at 9:44 PM, Kate Feng <kate007.feng at gmail.com> wrote:
>
>> Using -msoft-float is slower than using the hardware FPU.
>> The former one will kill real-time performance. -msoft-float is not
>> recommended to be used at the BSP level, unless the board does not
>> support hardware FP registers.  See more below......
>>
>> On Tue, Dec 10, 2013 at 12:36 PM, Joel Sherrill <Joel.Sherrill at oarcorp.com> wrote:
>>>
>>> GCC for the PowerPC will use floating point registers when you don't expect. Because of this all tasks are implicitly float on PPC. But in the bsp, there is concern for accidentally using the FPU in an ISR. This may be the sole reason soft float is used here.
>>
>> If the usage of the FPU could not be avoided in an ISR, then one
>> should explicitly save and restore the FP registers in the ISR.
>>
>> Cheers,
>> Kate Feng
>>>
>>> Would love to hear from Kate or another PowerPC BSP folks.
>>>
>>> On Dec 10, 2013 9:05 AM, Chirayu Desai <chirayudesai1 at gmail.com> wrote:
>>> Sorry for not being clear earlier, I want to know whether -msoft-float is required or not.
>>> If someone using the git HEAD (or RTEMS 4.10 or above) can verify that it is working without a problem, that would be great.
>>> -msoft-float was removed in rtems.git commit 7425411ff581a8f5c92a1266085e7eb1f4debd2b,
>>>
>>>
>>> On 10 December 2013 22:29, Chirayu Desai <chirayudesai1 at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> https://www.rtems.org/bugzilla/show_bug.cgi?id=1323
>>>> There is still an uncertainty regarding that bug, as the hardware does have a FPU, but looks like it was removed for some reason.
>>>>
>>>> git says this was introduced by commit ee732739bf9021a7a22de95eca9095c49b1d9169
>>>>
>>>>
>>>>
>>>> commit ee732739bf9021a7a22de95eca9095c49b1d9169
>>>>
>>>> Author: Joel Sherrill <joel.sherrill at OARcorp.com>
>>>>
>>>> Date:   Thu Sep 13 14:26:24 2007 +0000
>>>>
>>>>
>>>>
>>>>     2007-09-07      Kate Feng <feng1 at bnl.gov>
>>>>
>>>>
>>>>
>>>>         * ChangeLog, Makefile.am, README, README.booting, README.irq,
>>>>
>>>>         preinstall.am, GT64260/MVME5500I2C.c, include/bsp.h, irq/irq.c,
>>>>
>>>>         irq/irq.h, irq/irq_init.c, pci/detect_host_bridge.c, pci/pci.c,
>>>>
>>>>         pci/pci_interface.c, pci/pcifinddevice.c, start/preload.S,
>>>>
>>>>         startup/bspclean.c, startup/bspstart.c, startup/pgtbl_activate.c,
>>>>
>>>>         startup/reboot.c, vectors/bspException.h, vectors/exceptionhandler.c:
>>>>
>>>>         Merge my improvements in this BSP including a new network
>>>>
>>>>         driver for the 1GHz NIC.
>>>>
>>>>         * network/if_100MHz/GT64260eth.c, network/if_100MHz/GT64260eth.h,
>>>>
>>>>         network/if_100MHz/GT64260ethreg.h, network/if_100MHz/Makefile.am,
>>>>
>>>>         network/if_1GHz/Makefile.am, network/if_1GHz/POSSIBLEBUG,
>>>>
>>>>         network/if_1GHz/if_wm.c, network/if_1GHz/if_wmreg.h,
>>>>
>>>>         network/if_1GHz/pci_map.c, network/if_1GHz/pcireg.h: New files.
>>>>
>>>>
>>>> Anybody here who can test this on actual hardware and verify what is wrong with this?
>>>>
>>>>
>>>> Thanks.
>>>>
>>>> Chirayu Desai
>>>
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20131212/2684e593/attachment-0001.html>