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

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

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