[PATCH 4/4] arm: Support VFP-D32 and Neon

[Sebastian Huber]

On 05/10/2013 03:31 PM, Gedare Bloom wrote:
> On Fri, May 10, 2013 at 3:46 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de>  wrote:
>> >On 05/08/2013 07:39 PM, Claus, Ric wrote:
>>> >>
>>> >>Do all tasks pay the cost of context switching the FP context in this
>>> >>scheme, or just those tasks that are marked FP?  If there is only one FP
>>> >>task and many non-FP tasks in the system, is the FP context ever switched?
>> >
>> >
>> >All tasks and interrupts can use floating point operations.  The thread
>> >switch overhead is not that high (64 bytes to save/restore).  The interrupt
>> >entry and exit latency might be noticeable (196 bytes to save/restore).
>> >Everything has its price.  In theory it is possible to implement a lazy
>> >floating point context switching, but this is quite complex and I don't have
>> >the resources to implement it.
>> >
> This is architecture-dependent. grep for CPU_USE_DEFERRED_FP_SWITCH in
> cpukit/score/cpu and you can see which architectures support FP
> context switches only for FP tasks.

The lazy context switching approach is completely broken in RTEMS from my point 
of view.  The main problem is that GCC generates also floating point 
instructions for non-floating point tasks.  Newlib also provides a memcpy() 
implementation that uses Neon opcodes.

Currently the VFP+Neon support is actually only an extension of the integer 
processor context.  This is similar to the PowerPC SPE extension.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.