Subject: Re: IDT MIPS_RC32364 support
To: Chuck Cranor <chuck@research.att.com>
From: Jeff Smith <jeffs@geocast.com>
List: port-mips
Date: 08/30/2000 09:22:42
Chuck Cranor wrote:

> the reason i proposed it was because it is less limiting on where
> the kernel can run.
> 
> also, there is precedence, as we used self-modifying code on the
> sparc to handle some of the sun4/sun4c/sun4m differences.  [see
> the sparc locore.s, MUNGE() macro]

For the sparc this makes a lot of sense.  There are a lot of SUN
(and others) platforms that realistically can run the same kernel,
and there is a big benifit for ease of use.

On the other hand, a mips3ish 32b processor is probably for an
embedded system that will never have those demands on it.  If your
environment actually does, then it makes sense to be more run time
for ease of development.

That said, if you want to do dynamic code, that's ok too :-).  For
things like the tlb miss handlers, it's probably easier to have
a seperate code leaf that is chosen at runtime when the vectors
are hooked.

The people that have the most similar problem in mips is the hpcmips
folks as there are a number of "odd" mips processors used in the
various devices like the R39000.

jeffs