#
#  $Id$
#

There are various issues regarding this port:



1) Legal

This port is written by Andrew Bray <andy@i-cubed.co.uk>, and
is copyright 1995 i-cubed ltd.



2) CPU support.

This release fully supports the IBM PPC403GA and PPC403GB processors.

It has only been tested on the PPC403GA (using software floating
point).

With the gratefully acknowledged assistance of IBM and Blue Micro,
this release contains code to support the following processors
  PPC601, PPC603, PPC603e, PPC604, and PPC602.

The support for these processors is incomplete, especially that for
the PPC602 for which only sketchy data is currently available.



3) Application Binary INterface

In the context of RTEMS, the ABI is of interest for the following
aspects:

a)  Register usage.  Which registers are used to provide static variable
    linkage, stack pointer etc.

b)  Function calling convention.  How parameters are passed, how function
    variables should be invoked, how values are returned, etc.

c)  Stack frame layout.

I am aware of a number of ABIs for the PowerPC:

a)  The PowerOpen ABI.  This is the original Power ABI used on the RS/6000.
    This is the only ABI supported by versions of GCC before 2.7.0.

b)  The SVR4 ABI.  This is the ABI defined by SunSoft for the Solaris port
    to the PowerPC.

c)  The Embedded ABI.  This is an embedded ABI for PowerPC use, which has no
    operating system interface defined.  It is promoted by SunSoft, Motorola,
    and Cygnus Support.  Cygnus are porting the GNU toolchain to this ABI.

d)  GCC 2.7.0.  This compiler is partway along the road to supporting the EABI,
    but is currently halfway in between.

This port was built and tested using the PowerOpen ABI, with the following
caveat:  we used an ELF assembler and linker.  So some attention may be required
on the assembler files to get them through a traditional (XCOFF) PowerOpen
assembler.

This port contains support for the other ABIs, but this may prove to be incomplete
as it is untested.

In the long term, the RTEMS PowerPC port should move to the EABI as its primary
or only port.  This should wait on a true EABI version of GCC.

Andrew Bray 4/December/1995