[ECOS] Re: Ecos Port to PPC509/PPC555

[Bart Veer <bartv at cygnus dot co dot uk>]

I am falling behind on email, apologies.

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

Mostly correct, although one possible implementation requires no
changes to existing interfaces: add a boolean field to the context
structure to indicate whether or not the current thread has performed
any floating point; trap FP exceptions and set this boolean for the
current thread; have the context switch code and the interrupt
handling code do the right thing; I believe this implementation can be
done entirely inside the architectural HAL, without changing the
kernel or HAL interfaces, because all context-related code and all
hardware exception code is isolated there. However it is not
necessarily the correct implementation, or at least not the only
correct one.

    <snip>
    Sergei> You was right so far, but I can't agree with the last
    Sergei> statement. I'd prefer to don't save/restore FP context on
    Sergei> interrupts and all context switches. First, it is possible
    Sergei> to compile code that should never use FP with -msoft-float
    Sergei> to prevent compiler from generating FP instructions.

This is the first complication. Even if you compile most of eCos with
-msoft-float, there are some bits such as libm which you will probably
want to compile with -mhard-float. Furthermore these flags are only
applicable to the PowerPC architecture, other architectures may need
something different. In the current eCos build system there is no easy
way to support this, although an ugly kludge would be possible.
Furthermore the build system is undergoing heavy development at the
moment (and no, I cannot reveal the details just yet), so any such
kludge is likely to break for the next full release of eCos. There are
plans to sort this out properly, but it is a hard problem and it is
going to take time.

For the time being you would either have to build all of eCos with
-msoft-float, accepting performance penalties for libm, or you would
run the risk that things stop working in the next release.

    Sergei> For PowerPC it is possible to disable FP in MSR and get
    Sergei> exception if code executes FP instruction, then change
    Sergei> code to don't use constructs that are translated to FP
    Sergei> instructions (actually so far I soo only one place where
    Sergei> gcc generates FP for PowerPC: structure move operations,
    Sergei> and fixing this is very simple: just do per-member copy).

According to the relevant gcc maintainer the compiler may also use
floating point registers in other circumstances, mainly when it runs
out of integer registers and needs to cache some data temporarily.
This will only happen for code which has high register pressure. Of
course as the compiler optimisations become more aggressive this can
start happening more often.

It should be possible to add another compiler flag to gcc that
instructs it to use the floating point registers only for floating
point data, not for any other purposes. This would make life quite a
lot easier, and get around the compiler flags problem in the build
system as well. The best place for discussing such a change to the
compiler would be the egcs mailing list, see http://egcs.cygnus.com/
Although this should work for the PowerPC it might not be applicable
to some other architectures.

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

I can confirm that Cygnus is not currently working on enhancing the
floating point support. I have been informed that the PPC555 port that
is likely to be contributed in the near future does not have floating
point support either. Any code contributed in this area is welcome,
provided it meets the criteria set out in
http://sourceware.cygnus.com/ecos/faq.html#contrib_what Obviously
portability is a particular concern here.

I'll respond to your detailed proposal tomorrow.

Bart Veer // eCos net maintainer