Subject: Re: updates to evbmips, new common mips3 code
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-mips
Date: 09/03/2006 10:32:08
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