Re: updates to evbmips, new common mips3 code

Izumi Tsutsui wrote:
> [email protected] wrote:
>
>   
>> 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.
>>     
>
> Hmm, that's one of reasons why we have lkm binaries per ports?
> Anyway we already have many such macros (or inlines), and
> if you really want to have a common API, it have to handle
> all cases (including MIPS1) via a function pointer or something.
>
>   
>> (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?
>>     
>
> - not all MIPS3 CPUs are configured to use INT5 for internal comparematch
>   (on EWS4800/360, INT5 is connected to the external interval timer)
> - it isn't guaranteed that we can always get exact CPU frequency
>   (I don't know if there is any runtime variable clock systems though)
> - to share code between MIPS1 and MIPS3 models
>   (3MIN can have R3000 or R4000 daughter card on the same system board)
> etc?
>
> IMO it's the same reason why i386 still support i8254 timer too.
> ---
> Izumi Tsutsui
>   

Meanwhile, any complaints if I convert cobalt to use the MI todr
framework and timecounters?  I will just pull out the code from
mips3_clock.c, but I won't change the rest of cobalt's INT5 handling.

    -- Garrett

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