* [ECOS] Ecos Port to PPC509/PPC555 @ 1999-09-21 12:32 Ramana 1999-09-22 2:01 ` Sergei Organov 1999-09-23 8:16 ` [ECOS] " Bart Veer 0 siblings, 2 replies; 16+ messages in thread From: Ramana @ 1999-09-21 12:32 UTC (permalink / raw) To: ecos-discuss Hi, The PPC509/PPC555 are motorola processors of the power pc family. Does any body know if the powerpc port can operate on these processors. If not is a specific port available. Thanks for the help ramana b.v ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Ecos Port to PPC509/PPC555 1999-09-21 12:32 [ECOS] Ecos Port to PPC509/PPC555 Ramana @ 1999-09-22 2:01 ` Sergei Organov 1999-09-23 8:16 ` [ECOS] " Bart Veer 1 sibling, 0 replies; 16+ messages in thread From: Sergei Organov @ 1999-09-22 2:01 UTC (permalink / raw) To: ecos-discuss Hi, I also have MPC509 target as well as MPC555 evaluation board. Current eCos doesn't have ready support for these processor(s). The main trouble in porting eCos to this family is absence of floating point support in eCos. While FP support is in TO-DO list, it seems (based on current CVS snapshot) that actual work in this direction isn't yet started. If you don't need FP, then porting seems to be relatively easy. I'd like to participate in implementation of FP support for eCos. What is current status? Does anybody at Cygnus take care of FP? Regards, Sergei Organov. Ramana <ramanabv@danlawinc.com> writes: > Hi, > The PPC509/PPC555 are motorola processors of the power pc family. Does > any body know if the powerpc port can operate on these processors. If > not is a specific port available. > Thanks for the help > ramana b.v ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-21 12:32 [ECOS] Ecos Port to PPC509/PPC555 Ramana 1999-09-22 2:01 ` Sergei Organov @ 1999-09-23 8:16 ` Bart Veer 1999-09-24 4:39 ` Sergei Organov 1 sibling, 1 reply; 16+ messages in thread From: Bart Veer @ 1999-09-23 8:16 UTC (permalink / raw) To: ramanabv, osv; +Cc: ecos-discuss >>>>> "Ramana" == Ramana <ramanabv@danlawinc.com> writes: Ramana> The PPC509/PPC555 are motorola processors of the power pc Ramana> family. Does any body know if the powerpc port can operate Ramana> on these processors. If not is a specific port available. and >>>>> "Sergei" == Sergei Organov <osv@Javad.RU> writes: Sergei> I also have MPC509 target as well as MPC555 evaluation Sergei> board. Current eCos doesn't have ready support for these Sergei> processor(s). The main trouble in porting eCos to this Sergei> family is absence of floating point support in eCos. While Sergei> FP support is in TO-DO list, it seems (based on current Sergei> CVS snapshot) that actual work in this direction isn't yet Sergei> started. If you don't need FP, then porting seems to be Sergei> relatively easy. Sergei> I'd like to participate in implementation of FP support Sergei> for eCos. What is current status? Does anybody at Cygnus Sergei> take care of FP? Sergei is correct, the current PowerPC HAL packages do not support the MPC555. There has been a port to this processor outside Cygnus, which was going to be contributed and incorporated into the mainline sources. I have not heard anything recently about the status of this port, but have pinged the person involved. 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 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. If your application does not use floating point and you use the compiler flag -msoft-float then you can get improved context switch and interrupt response times, but the compiler has less scope to optimise code. Bart Veer // eCos net maintainer ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-23 8:16 ` [ECOS] " Bart Veer @ 1999-09-24 4:39 ` Sergei Organov 1999-09-24 8:52 ` Jonathan Larmour 1999-09-27 11:54 ` Bart Veer 0 siblings, 2 replies; 16+ messages in thread From: Sergei Organov @ 1999-09-24 4:39 UTC (permalink / raw) To: ecos-discuss 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-24 4:39 ` Sergei Organov @ 1999-09-24 8:52 ` Jonathan Larmour 1999-09-24 10:34 ` Sergei Organov 1999-09-27 11:54 ` Bart Veer 1 sibling, 1 reply; 16+ messages in thread From: Jonathan Larmour @ 1999-09-24 8:52 UTC (permalink / raw) To: Sergei Organov; +Cc: ecos-discuss Sergei Organov wrote: > > 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. Yep. This is a sensible optimization, but yes it would require HAL changes. The clever thing is implementing an interface that won't affect other HALs - some MCUs will never have hard floating-point so we shouldn't be complicating their implementations unnecessarily. It also has to be configurable because some interrupt/exception handlers may want to use FP of course. > 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. Not if you contribute it back! If you want to propose something more concrete on this list, everyone can discuss it. Cygnus aren't working on it, but we will do what we can to help you do it. If you submit acceptable patches to the list, we will certainly incorporate it in future releases. eCos really is open source :-). 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-24 8:52 ` Jonathan Larmour @ 1999-09-24 10:34 ` Sergei Organov 0 siblings, 0 replies; 16+ messages in thread From: Sergei Organov @ 1999-09-24 10:34 UTC (permalink / raw) To: ecos-discuss I agree with every word in your reply. And I understand that eCos is open source. I just wanted to make sure that if I begin work on FP support, I will not do it in parallel with somebody else either inside or outside Cygnus. Now when I've got exact answer, I'm going to write down my thoughts how it could be implemented and post them here for discussion. Hope I'll have time to do it next week. Regards, Sergei. Jonathan Larmour <jlarmour@cygnus.co.uk> writes: > Sergei Organov wrote: > > > > 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. > > Yep. This is a sensible optimization, but yes it would require HAL changes. > The clever thing is implementing an interface that won't affect other HALs - > some MCUs will never have hard floating-point so we shouldn't be > complicating their implementations unnecessarily. > > It also has to be configurable because some interrupt/exception handlers may > want to use FP of course. > > > 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. > > Not if you contribute it back! If you want to propose something more > concrete on this list, everyone can discuss it. Cygnus aren't working on it, > but we will do what we can to help you do it. If you submit acceptable > patches to the list, we will certainly incorporate it in future releases. > eCos really is open source :-). > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-24 4:39 ` Sergei Organov 1999-09-24 8:52 ` Jonathan Larmour @ 1999-09-27 11:54 ` Bart Veer 1999-09-27 17:36 ` Jonathan Larmour 1999-09-28 4:19 ` Sergei Organov 1 sibling, 2 replies; 16+ messages in thread From: Bart Veer @ 1999-09-27 11:54 UTC (permalink / raw) To: osv; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-27 11:54 ` Bart Veer @ 1999-09-27 17:36 ` Jonathan Larmour 1999-09-28 4:23 ` Sergei Organov 1999-09-28 8:00 ` Bart Veer 1999-09-28 4:19 ` Sergei Organov 1 sibling, 2 replies; 16+ messages in thread From: Jonathan Larmour @ 1999-09-27 17:36 UTC (permalink / raw) To: bartv; +Cc: osv, ecos-discuss Bart Veer wrote: > > >>>>> "Sergei" == Sergei Organov <osv@Javad.RU> 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. > <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. 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-27 17:36 ` Jonathan Larmour @ 1999-09-28 4:23 ` Sergei Organov 1999-09-28 7:42 ` Jonathan Larmour 1999-09-28 8:00 ` Bart Veer 1 sibling, 1 reply; 16+ messages in thread From: Sergei Organov @ 1999-09-28 4:23 UTC (permalink / raw) To: ecos-discuss Jonathan Larmour <jlarmour@cygnus.co.uk> writes: > [...] > 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. Isn't it better to just fix *printf/*scanf to don't use FP when it is not required by input format. Or am I missing something and this is just impossible? Sergei. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-28 4:23 ` Sergei Organov @ 1999-09-28 7:42 ` Jonathan Larmour 0 siblings, 0 replies; 16+ messages in thread From: Jonathan Larmour @ 1999-09-28 7:42 UTC (permalink / raw) To: Sergei Organov; +Cc: ecos-discuss Sergei Organov wrote: > > Jonathan Larmour <jlarmour@cygnus.co.uk> writes: > > > [...] > > 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. > > Isn't it better to just fix *printf/*scanf to don't use FP when it is > not required by input format. Or am I missing something and this is > just impossible? I suppose you could separate out the vararg extraction into a separate function (and make sure that function could never be inlined), but it would be non-trivial given the "design" of Berkeley printf/scanf from which the eCos version is derived. 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-27 17:36 ` Jonathan Larmour 1999-09-28 4:23 ` Sergei Organov @ 1999-09-28 8:00 ` Bart Veer 1999-09-28 8:02 ` Jonathan Larmour 1 sibling, 1 reply; 16+ messages in thread From: Bart Veer @ 1999-09-28 8:00 UTC (permalink / raw) To: jlarmour; +Cc: ecos-discuss >>>>> "Jifl" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes: >> 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] Jifl> But you can't rely on FP exceptions being generated - they Jifl> don't for normal code, so I don't believe this is a viable Jifl> option unless I've misunderstood you. On some architectures including the PPC (if I remember correctly), it is possible to disable the floating point unit. The first operation that attempts to access the floating point unit, even if it is just to access a floating point register, will cause a hardware exception. This is separate from normal floating point exceptions such as overflow. >> <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. Jifl> Actually yes we do - the existing Configuration Tool allows Jifl> the overriding of flags on a per-package basis (although no Jifl> finer granularity than that). Its under Build->Options... In the current build system there is some support to do this on a per-package basis, but not automatically. It is necessary to create some additional files, either manually or via the configuration tool. This is not really acceptable for what is proposed here, and anyway package-based granularity may not be good enough. Also I am not sure we have ever documented how this part of the build system worked, and it will change for the next release. Bart Veer // eCos net maintainer ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-28 8:00 ` Bart Veer @ 1999-09-28 8:02 ` Jonathan Larmour 0 siblings, 0 replies; 16+ messages in thread From: Jonathan Larmour @ 1999-09-28 8:02 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss Bart Veer wrote: > > >>>>> "Jifl" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes: > Jifl> But you can't rely on FP exceptions being generated - they > Jifl> don't for normal code, so I don't believe this is a viable > Jifl> option unless I've misunderstood you. > > On some architectures including the PPC (if I remember correctly), it > is possible to disable the floating point unit. The first operation > that attempts to access the floating point unit, even if it is just to > access a floating point register, will cause a hardware exception. > This is separate from normal floating point exceptions such as > overflow. Oops yes. I did misunderstand you :-). For what its worth, MIPS and x86 have this as well IIRC. 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-27 11:54 ` Bart Veer 1999-09-27 17:36 ` Jonathan Larmour @ 1999-09-28 4:19 ` Sergei Organov 1999-09-28 8:08 ` Jonathan Larmour 1999-09-28 11:03 ` Bart Veer 1 sibling, 2 replies; 16+ messages in thread From: Sergei Organov @ 1999-09-28 4:19 UTC (permalink / raw) To: ecos-discuss Bart Veer <bartv@cygnus.co.uk> writes: [...] > 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. Agreed. It seems I see how to do it at least for PowerPC. But it's questionable that FP-enable bit found in PowerPC MSR or similar is available on any FP architecture, and thus there could be no way to get exception from code that just uses FP operations. [...] > 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. Thanks for warning. It'd be fine if you post details as soon as you can. Don't know if you are going to implement it, but it seems to be a good thing to be able to describe dependencies between packages. Something like Debian does comes to mind (ability to put "requires" and "conflicts" statements into package description). > > 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. No, I'd better build all eCos with -mhard-float. The only significant trouble is 'printf' and friends where FP code isn't separated from non-FP, and thus generated code contains FP registers save/restore in prologue and epilogue. While I don't have time to fix 'printf', I'll just don't use it in threads that have no FP context. And I'll use FP-enable bit of MSR to get exceptions if non-FP task uses FP operation. For me it seems to be more acceptable way until eCos configuration system evolves to 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). > > 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. True. It's very compiler dependent. However, still I see that gcc uses stack when there are not enough registers. Maybe I just didn't run into such circumstances, though. > > 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. Well, this idea came to my mind as well. The pair -m[soft/hard]-float needs -mno-float to be complete. If it's not applicable to some architecture, it apparently means that for given architecture FP context just couldn't be separated, and thus there is no need for special support for separate FP context in eCos for this architecture, I think. I'm aware of egcs mailing lists, but I'm afraid there was not enough demand so far for such an option to be implemented. Maybe further eCos development will produce such demand. [...] Regards, Sergei. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-28 4:19 ` Sergei Organov @ 1999-09-28 8:08 ` Jonathan Larmour 1999-09-28 11:03 ` Bart Veer 1 sibling, 0 replies; 16+ messages in thread From: Jonathan Larmour @ 1999-09-28 8:08 UTC (permalink / raw) To: Sergei Organov; +Cc: ecos-discuss, Bart Veer, Nick Garnett Sergei Organov wrote: > > No, I'd better build all eCos with -mhard-float. The only significant > trouble is 'printf' and friends where FP code isn't separated from > non-FP, and thus generated code contains FP registers save/restore in > prologue and epilogue. As Bart pointed out to me in person earlier, the calling conventions will be screwed up when calling to/from a module compiled with -msoft-float from/to a module compiled with -mhard-float. So I think trying to mix types of code built with these options is probably a lost cause I'm afraid. And getting gcc not to use the FP registers under any circumstances is only an "optimization" really, especially since it seems to only happen under extreme register pressure. The worst that can happen is unnecessary FP context saves. However I think your detailed proposal looks sound in principle. Our kernel guru is just back from a two-week holiday and should be able to comment when he gets to the bottom of his e-mail (which may take some time!). We won't be forgetting you :-). 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Re: Ecos Port to PPC509/PPC555 1999-09-28 4:19 ` Sergei Organov 1999-09-28 8:08 ` Jonathan Larmour @ 1999-09-28 11:03 ` Bart Veer 1 sibling, 0 replies; 16+ messages in thread From: Bart Veer @ 1999-09-28 11:03 UTC (permalink / raw) To: osv; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [ECOS] Ecos Port to PPC509/PPC555 @ 1999-09-21 12:34 Ramana 0 siblings, 0 replies; 16+ messages in thread From: Ramana @ 1999-09-21 12:34 UTC (permalink / raw) To: ecos-discuss Hi, The PPC509/PPC555 are motorola processors of the power pc family. Does any body know if the powerpc port can operate on these processors. If not is a specific port available. Thanks for the help ramana b.v ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-09-28 11:03 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-21 12:32 [ECOS] Ecos Port to PPC509/PPC555 Ramana 1999-09-22 2:01 ` Sergei Organov 1999-09-23 8:16 ` [ECOS] " Bart Veer 1999-09-24 4:39 ` Sergei Organov 1999-09-24 8:52 ` Jonathan Larmour 1999-09-24 10:34 ` Sergei Organov 1999-09-27 11:54 ` Bart Veer 1999-09-27 17:36 ` Jonathan Larmour 1999-09-28 4:23 ` Sergei Organov 1999-09-28 7:42 ` Jonathan Larmour 1999-09-28 8:00 ` Bart Veer 1999-09-28 8:02 ` Jonathan Larmour 1999-09-28 4:19 ` Sergei Organov 1999-09-28 8:08 ` Jonathan Larmour 1999-09-28 11:03 ` Bart Veer 1999-09-21 12:34 [ECOS] " Ramana
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).