Subject: Re: updates to evbmips, new common mips3 code
To: None <garrett_damore@tadpole.com>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: port-evbmips
Date: 09/04/2006 02:22:13
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.

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