[ECOS] Ecos Port to PPC509/PPC555

[ECOS] Ecos Port to PPC509/PPC555

[Ramana]

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

Re: [ECOS] Ecos Port to PPC509/PPC555

[Sergei Organov]

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

[ECOS] Re: Ecos Port to PPC509/PPC555

[Bart Veer]

>>>>> "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

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Sergei Organov]

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.

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Jonathan Larmour]

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

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Sergei Organov]

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

[ECOS] Re: Ecos Port to PPC509/PPC555

[Bart Veer]

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

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Jonathan Larmour]

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

[ECOS] Re: Ecos Port to PPC509/PPC555

[Sergei Organov]

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.

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Sergei Organov]

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.

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Jonathan Larmour]

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

[ECOS] Re: Ecos Port to PPC509/PPC555

[Bart Veer]

>>>>> "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

[ECOS] Re: Ecos Port to PPC509/PPC555

[Jonathan Larmour]

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

Re: [ECOS] Re: Ecos Port to PPC509/PPC555

[Jonathan Larmour]

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

[ECOS] Re: Ecos Port to PPC509/PPC555

[Bart Veer]

>>>>> "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