Subject: Re: NOTICE: thorpej-mips-cache branch will be merged today
To: None <port-mips@netbsd.org>
From: Simon Burge <simonb@wasabisystems.com>
List: port-mips
Date: 11/21/2001 18:25:26
cgd@broadcom.com wrote:
> locore32@gaea.ocn.ne.jp ("Toru Nishimura") writes:
> > > I notice in your diff you say:
> > >
> > > +# Invalid combinations are
> > > +# * MIPS1_3000 && (MIPS1_3900 || MIPS1_3920)
> > > +# * (MIPS3_4000 || MIPS3_4600 || MIPS3_5000) && MIPS3_4100
> > > +# * (MIPS3_4000 || MIPS3_4600 || MIPS3_5000) && MIPS3_5900
> > > +# * MIPS3_4100 && MIPS3_5900
> > >
> > > Why are these actually invalid combinations? (that seems bogus...)
> >
> > How about categorize and collerate the functional aspect of CPU designs
> > instead of patch works to fill holes like that?
> >
> > - TLB
> > R3KTLB or R4KTLB (possibly R4KTLB64 for LP64)
> > - cache
> > R3KCACHE, R4KCACHE (, R5KCACHE) or TX39CACHE ...
> > - FP registers
> > FPPAIRED32 (thirty-two 32bit), FPDOUBLE (thirty-two 64bit) or FPSINGLE (sorta)
> > - others necessary...
>
> Err, uh, users _definitely_ shouldn't have to think about _these_ in
> their config files.
>
> While there's some chance that they'll know what kind of CPU is in
> their box, it seems ... unlikely that they'll know enough about its
> cp0 to intelligently pick among these...
At the kernel config file level (more likely in foo/conf/foo.std except
for archs like pmax and newsmips where multiple different CPU ISAs are
used), we probably only want:
MIPS1
MIPS3 (or MIPS3PLUS maybe more correctly, but that name sucks)
MIPS32
MIPS64
Having some mechanism for only compiling in support for a specific CPU
might be a win for really low memory machines, but realistically the
extra code isn't that large. I think that's something we could work
towards later _if_ it proves to be a problem.
One problem is dealing with CPU id's that are duplicated - these either
require kernel config options or Magick during detection.
Internal management of multiple cpu types is obviously totally different
- I'm working on this at the moment and hope to have something ready for
review in the near future...
Simon.
--
Simon Burge <simonb@wasabisystems.com>
NetBSD CDs, Support and Service: http://www.wasabisystems.com/