Izumi Tsutsui wrote:
> garrett_damore@tadpole.com 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.
>   

Yes, on MIPS1 & MIPS3 combined kernels (pmax), you need a function
pointer.  (This starts to ask the question about why we have a single
generic kernel supporting both CPU models, but I'm told such thoughts
are heresy.)

>   
>> (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)
>   
Okay, I didn't know that.  It makes sense, though.  If someone who is
using these boards wants to try to break up the code in mips3_clock.c to
permit better sharing, I'd encourage it.  I don't know the constraints
on all designs, so I won't worry about it.

> - it isn't guaranteed that we can always get exact CPU frequency
>   

Hmm... that's "interesting".

>   (I don't know if there is any runtime variable clock systems though)
>   

I wondered about that, too.  For now I've not worried about it.

> - to share code between MIPS1 and MIPS3 models
>   (3MIN can have R3000 or R4000 daughter card on the same system board)
> etc?
>   

See my comments above about pmax.  If someone wants to clean it up,
please feel free.

    -- Garrett
> IMO it's the same reason why i386 still support i8254 timer too.
> ---
> Izumi Tsutsui
>   


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