This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: Ecos Port to PPC509/PPC555
- To: ramanabv at danlawinc dot com, osv at Javad dot RU
- Subject: [ECOS] Re: Ecos Port to PPC509/PPC555
- From: Bart Veer <bartv at cygnus dot co dot uk>
- Date: Thu, 23 Sep 1999 15:48:06 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- References: <37E80554.7D56118D@danlawinc.com>
- Reply-to: bartv at cygnus dot co dot uk
>>>>> "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