From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: bartv@cygnus.co.uk Cc: osv@Javad.RU, ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] Re: Ecos Port to PPC509/PPC555 Date: Mon, 27 Sep 1999 17:36:00 -0000 Message-id: <37F00D1F.FDEC9E27@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> X-SW-Source: 1999-09/msg00043.html Bart Veer wrote: > > >>>>> "Sergei" == Sergei Organov writes: > Sergei> 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. > > 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; [snip] But you can't rely on FP exceptions being generated - they don't for normal code, so I don't believe this is a viable option unless I've misunderstood you. > > 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. Actually yes we do - the existing Configuration Tool allows the overriding of flags on a per-package basis (although no finer granularity than that). Its under Build->Options... Certainly one problem with doing this for (e.g.) libm is that sometimes functions in there get called from all around the place, e.g. *printf/*scanf. So there's a lot of scope for programmer error if they think a thread doesn't ever need an FP context. Something to bear in mind anyway. Jifl -- Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762 "I used to have an open mind but || Get yer free open source RTOS's here... my brains kept falling out." || http://sourceware.cygnus.com/ecos Help fight spam! http://spam.abuse.net/ These opinions are all my own fault