powerpc-rtems-4.7-gcc-4.0 patch commited

Ralf Corsepius ralf.corsepius at rtems.org
Fri Feb 18 14:20:16 UTC 2005


On Fri, 2005-02-18 at 06:24 -0600, Joel Sherrill  wrote:
> 
> 
> > E.g. the m8260 would be superflous, if it could be removed from cpukit.
> > The code it uses is _identical_ to the 603e, except of 1 define in
> > cpukit.
> 
> OK. Are you referring to this code?
> 
> #if (defined(ppc403) || defined(mpc860) || defined(mpc821) || 
> defined(mpc8260))
>    uint32_t     serial_per_sec;         /* Serial clocks per second */
>    boolean      serial_external_clock;
>    boolean      serial_xon_xoff;
>    boolean      serial_cts_rts;
>    uint32_t     serial_rate;
>    uint32_t     timer_average_overhead; /* Average overhead of timer in 
> ticks */
>    uint32_t     timer_least_valid;      /* Least valid number from timer 
>       */
>    boolean      timer_internal_clock;   /* TRUE, when timer runs with 
> CPU clk */
> #endif
> 
> #if (defined(mpc555) || defined(mpc860) || defined(mpc821) || 
> defined(mpc8260))
>    uint32_t     clock_speed;            /* Speed of CPU in Hz */
> #endif
> 
> These are the HW configuration parameters required by  portions of 
> libcpu which are provided by the BSP.  How about another mechanical fix?
> Two alternatives:
> 
>    + Define this as a structure that is provided by the BSP.
>    + Like other portions of libcpu, assume that the BSP is providing
>      a single global variable like "BSP_clock_speed" and change the
>      code in libcpu to use it.
Cf. what I wrote a couple of minutes ago.

We need data abstraction, not defines.

> However it is done, it is BSP specific information required by libcpu 
> code.  No reason for it to be defined in cpukit.
> 
> That would seem to eliminate the need for mpc555, mpc860, mpc8260, and 
> mpc821.
> 
> 
> >>Note that a #ifdef __mpcXXX in a BSP is *not* a valid reason as the 
> >>respective compiler
> > 
> > Right.
> > 
> > 
> >>The only (legacy) reason I can think of are #ifdef __mpcXXX in cpukit 
> >>and/or libcpu - however,
> >>these should be cleaned up.
> > 
> > Fully agreed. 
> > 
> > Eg. let's implement a common API, shared between old and new exception
> > processing. Lack of this is the cause for at least 3 multilib variants.
> 
> Can you point me to a specific ifdef to nibble on?
At the moment ,the brute force fix would be to remove all these defines
and to add these variables unconditionally.

Ralf






More information about the users mailing list