From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bart Veer To: osv@Javad.RU Cc: ecos-discuss@sourceware.cygnus.com Subject: [ECOS] Re: Ecos Port to PPC509/PPC555 Date: Tue, 28 Sep 1999 11:03:00 -0000 Message-id: <199909281802.TAA12410@sheesh.cygnus.co.uk> References: <37E80554.7D56118D@danlawinc.com> <199909231448.PAA13861@sheesh.cygnus.co.uk> <87puz8v8sh.fsf@osv.javad.ru> <199909271854.TAA26830@sheesh.cygnus.co.uk> <877llbz3ix.fsf@osv.javad.ru> X-SW-Source: 1999-09/msg00054.html >>>>> "Sergei" == Sergei Organov 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