powerpc-rtems-4.7-gcc-4.0 patch commited

[Joel Sherrill <joel@OARcorp.com>]

Sergei Organov wrote:
> "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
> [...]
> 
>>There is a PPC_INTERRUPTS_MAX which still remains to be addressed.
>>Ralf.. I think the the MIPS defines that in libcpu as a variable used by the
>>cpukit.
> 
> 
> IMHO, it's time to define generic interface between cpukit and the rest
> of RTEMS BSP that will ensure compile-time independence of cpukit, or at
> least to document some guidelines. It seems that pre-multilib BSP
> interface definitions don't address the issue as in fact every BSP is
> now split between cpukit and the rest of libs and there is no definition
> of the interface to be used on this split line. Does it sound
> reasonable?

That largely exists.  When we started splitting the CPU kit from the BSP
and libcpu parts of the tree, most of the ports were clean.  The porting 
guide is in general pretty close.  The PowerPC and MIPS were the worst 
cases to handle.  I reworked the MIPS a few years ago to be more general
and it has continued to evolve as we learn more about different ISA 
variants.

The PowerPC port had more problems in this respect than the other ports
and now it stands alone as the biggest hurdle remaining.  Without 
assigning blame, this is due to a number of factors:

   + age and evolution of the port -- the 60x CPUs were included in the
     first submitted port as "book based only"
   + many flags based on CPU models because there was no clear direction
     5-10 years ago on how many cores there would be and what would be
     common
   + old vs new exception models.
   + desire not to break existing code.

libcpu was NOT even a thought when the original PowerPC was submitted. 
We are now just paying the price for history and learning as we go.

The rules for cpukit vs bspkit are actually quite simple.  If gcc 
distinguishes a variant, then cpukit can know about it.  If that variant 
is not detailed enough to distinguish two CPU cores that CPUkit has to 
know about, then we have to address that. The rub is that there seems to 
be one unique piece of the port for each architecture that you have to 
based on cpu model not ISA variant. It might be number of interrupts or 
status register bits that are valid, etc, etc.


Notice how the PowerPC port is evolving now.  Ralf proposed some 
conditionals to remove/consolidate, then reduced the multilibs.  Then 
everyone jumped in and said "you can remove that" or "why is that 
there?".  Once the mess is straightened out, it will really be quite 
simple.

If everyone keeps offering constructive criticism and saying CPU X and Y 
should be able to use the same multilib, then we will make it.

The next step will be getting help comparing .S files in various BSPs 
and seeing if we can consolidate them under fewer files.  No one can 
test every variant but with care, we should be able to reduce them 
mechanically with little risk.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985