How to add CPU_MODEL
strauman at slac.stanford.edu
Wed Oct 15 20:33:39 UTC 2008
Just my 2-cents:
PPC has been plagued with a jungle of
which is a nightmare to maintain.
- do not use / implement exotic features that provide small gain
(especially such features that are likely to disappear in future
versions of the CPU)
- use run-time detection as much as possible
- keep CPU-specifica in a dedicated library rather than
sprinkling #ifdefs all over the code-base.
- do NOT advocate creation of a new gcc multilib if
this only for the purpose of getting a -D_my_cpu_flavor
symbol defined. gcc multilibs should ONLY be used
- differences in API
- difference in instruction set (includes co-processors)
- *NOTHING* that does not affect gcc's code generation
in a binary-incompatible way justifies a multilib.
E.g., if you do magic using assembly
code then you normally don't need special gcc flags.
Gcc does not know what 'special' instructions you use
from assembly code.
- keep cpu-flavor specific stuff which cannot be switched
at run-time and where you must use conditionally compiled code
out of cpukit. You can then -D_my_cpu_flavor in the BSP's
'custom' Makefile snippet.
Leon Pollak wrote:
> Hello, all.
> I've spent a lot of time reading the docs and must admit that still not
> I am using MPC8247 which is the "sub-model" of MPC8272 which is in
> turn "sub-model" of MPC8260.
> First of all, RTEMS tree does not recognize the MPC82xx family, but has only
> MPC8260. I saw very few references to mpc8242, but too few to understand how
> it works.
> But there are some differences between all these models which I do not know
> how to treat locally in BSP files. For example, the MPC8260 has 16KB+4KB
> dpram, while MPC8272 has 8KB+4KB. Or MPC8247 does not have SCC2, while
> MPC8260 does have. And so on.
> Where can I find some help to read about adding the CPU model without loosing
> most of the "main" processor (MPC8260 in my case) features?
> Thanks ahead.
More information about the users