[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
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
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
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
+ 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
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