[ECOS] Re: Ecos Port to PPC509/PPC555

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

>>>>> "Sergei" == Sergei Organov <osv@Javad.RU> writes:

    Sergei> [...]
    >> 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.

    Sergei> Thanks for warning. It'd be fine if you post details as
    Sergei> soon as you can. Don't know if you are going to implement
    Sergei> it, but it seems to be a good thing to be able to describe
    Sergei> dependencies between packages. Something like Debian does
    Sergei> comes to mind (ability to put "requires" and "conflicts"
    Sergei> statements into package description).

Yes. In fact the intention is to go quite a bit beyond that...

    >> 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> No, I'd better build all eCos with -mhard-float. The only
    Sergei> significant trouble is 'printf' and friends where FP code
    Sergei> isn't separated from non-FP, and thus generated code
    Sergei> contains FP registers save/restore in prologue and
    Sergei> epilogue. While I don't have time to fix 'printf', I'll
    Sergei> just don't use it in threads that have no FP context. And
    Sergei> I'll use FP-enable bit of MSR to get exceptions if non-FP
    Sergei> task uses FP operation. For me it seems to be more
    Sergei> acceptable way until eCos configuration system evolves to
    Sergei> give clean ability to handle this.

    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).

I do not know how much (if any) of eCos currently uses structure move
operations. If changes were needed to lots of existing code then this
could be a problem, and new structure copies could be introduced at
any time. This does not preclude doing things as per your approach,
but it may limit the performance gains that can be achieved until the
eCos build system provides the appropriate functionality.

Bart Veer // eCos net maintainer