Re: updates to evbmips, new common mips3 code

Izumi Tsutsui wrote:
> [email protected] wrote:
>
>   
>> I've moved a significant amount of the clock interrupt and related
>> functionality from evbmips to a common file, arch/mips/mips/mips3_clock.c
>>
>> This means that ports which want to use the CP0 counter register for
>> their system clock can just use this, and remove a lot of MD code for
>> it.  Look at evbmips for an example.  Of particular note, you might want
>> to look at the before/after for evbmips/evbmips/interrupt.c, because
>> that shows how to rip out the clock interrupt handler and replace with a
>> call to mips3_clockintr().
>>     
>
> Could you please rename cpu_initclocks(), setstatclockrate(), and
> delay() in mips3_clock.c to names with mips3 (or something) prefixed?
> Some mips ports require some MD stuff in these functions, or
> they might use function pointers to switch these functions
> (especiall for ports which share code with MIPS1 and MIPS3 models).
>
> Ports which don't require such MD tweak can just have macros like:
> #define delay(x) mips3_delay(x)
> in <machine/param.h> etc.
> ---
> Izumi Tsutsui
>   

There has been discussion with Simon about this.  I think we'll probably
change it, but I'm waiting for Simon to decide how to handle it.  (In
other words, I agree that this could be done better.  I just don't know
what the best way to do it is.)

FWIW, I'm not too fond of using macros to rename functions, because the
_ABI_ difference makes it harder for binary modules.  Its helpful to
have a common API.  Use of #pragma weak might be one way to alias
symbols for the ports that need it without imposing another call frame.

(This came up for pmax or somesuch, that wants both mips1 and mips3
code.)  FWIW, I think _all_ mips3 ports could benefit from using this
code -- I can't imagine any reason why we would not want to use MIPS
INT5 for the system clock.  Having more variations just makes the code
harder to maintain and increases the MD code size.  Unless I'm missing
something silly?

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191