[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: powerpc-rtems-4.7-gcc-4.0 patch commited



Sergei Organov wrote:
"Joel Sherrill <joel@OARcorp.com>" <joel.sherrill@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@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985