Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Sergei Organov <osv@Javad.RU>]

Bart Veer <bartv@cygnus.co.uk> writes:
[...]
> I do not know whether or not this MPC555 port includes floating point
> support. Cygnus has implemented hardware floating point support for
> one architecture, the VR4300, but this port has not yet been generally
> released. Based on this experience very little needs to be done to the
> system to support hardware floating point. There is code to manipulate
> thread contexts in the architectural HAL packages, and obviously this
> will need to be updated to include the floating point registers. The
> interrupt handling code will be affected as well, and you may want to
> worry about additional exceptions that may get raised. As far as I am
> aware there was little or no code outside the HAL packages that had
> to be changed.

You are definitely right for the simplest possible FP support
implementation. However, let's look a little bit further. I don't want 
to have FP overhead for every task in my system. Actually only few
tasks should have floating point context, and the rest of tasks never
use floating point. Therefore it is required to somehow specify if
given task has FP context or not. This requires change(s) to the
kernel API. Optimizing further, if only some tasks have FP context,
then FP context switch is actually required only when control is given 
to FP task. Such lazy FP context switch requires some support from
kernel and apparently some changes in HAL interface.

> 
> You should be aware of one complication. For some architectures the
> compiler may make use of floating point registers even if the
> application code does not involve floating point arithmetic. If the
> compiler runs out of integer registers then it may temporarily store
> values in a floating point register rather than on the stack. Also
> structure move operations and the like can sometimes be done more
> efficiently using the floating point registers.
> 
> I have checked with the appropriate gcc maintainer, and the PowerPC
> compiler will make use of the floating point registers in this way if
> you explicitly enable -mhard-float or set the cpu type to e.g.
> -mcpu=603. Therefore the HAL packages always have to save floating
> point state during context switching or interrupts.

You was right so far, but I can't agree with the last statement. I'd
prefer to don't save/restore FP context on interrupts and all context
switches. First, it is possible to compile code that should never use
FP with -msoft-float to prevent compiler from generating FP
instructions. For PowerPC it is possible to disable FP in MSR and get
exception if code executes FP instruction, then change code to don't
use constructs that are translated to FP instructions (actually so far
I soo only one place where gcc generates FP for PowerPC: structure
move operations, and fixing this is very simple: just do per-member
copy).

Overall, I'd prefer to have full FP support in eCos to be able to use
all possible tricks to get maximum performance from hardware. That's
why I asked about FP support in eCos - I meant general support, and
not FP context save/restore implementation for some particular
architecture. Sure, I can do all this myself, but then another
implementation will come from Cygnus. So the question remains.

Regards,
Sergei Organov.