[Top] [All Lists]

Re: broken RM7000 in CVS

To: Jun Sun <>
Subject: Re: broken RM7000 in CVS
From: Geert Uytterhoeven <>
Date: Tue, 16 Jan 2001 07:46:39 +0100 (MET)
Cc: Justin Carlson <>,
In-reply-to: <>
On Mon, 15 Jan 2001, Jun Sun wrote:
> 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.
> 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).

Yes. But the advantage of the switch (`code table') over a data table is that
you can easier incorporate tests for special cases.



Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

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