linux-mips
[Top] [All Lists]

Re: broken RM7000 in CVS

To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Subject: Re: broken RM7000 in CVS
From: Jun Sun <jsun@mvista.com>
Date: Mon, 15 Jan 2001 10:45:22 -0800
Cc: Justin Carlson <carlson@sibyte.com>, linux-mips@oss.sgi.com
References: <Pine.GSO.4.10.10101150730420.4392-100000@escobaria.sonytel.be>
Sender: owner-linux-mips@oss.sgi.com
Geert Uytterhoeven wrote:
> 
> On Fri, 12 Jan 2001, Justin Carlson wrote:
> > I still would rather stick to the switch style of doing things in the 
> > future,
> > though, because it's a bit more flexible; if you've got companies that fix
> > errata without stepping PrID revisions or some such, then the table's going 
> > to
> > have some strange special cases that don't quite fit.
> >
> > But this is much more workable than what I *thought* you were proposing.  
> > And
> > not worth nearly as much trouble as I've been giving you over it.
> 
> Then don't use a probe table, but a switch based CPU detection routine that
> fills in a table of function pointers. So you need the switch only once.
> 

Geert,

Is there some concerns about using table?

mips_cpu structure is probably a mixture of data and function pointers.  To
use a switch statement, one either supplies a function which will fill out the
rest of member data in the structure, or fills in all the member data in the
case block.  Compared with the table solution, the former case is too
restricting (it mandates every CPU has its own "setup" routine") and the later
case is less clean-looking.

Performance-wise table should be basically identical to switch statements.  It
is a linear search of some integers (PrID).

Jun

<Prev in Thread] Current Thread [Next in Thread>