Re: broken RM7000 in CVS

Re: broken RM7000 in CVS

[Justin Carlson]

On Fri, 12 Jan 2001, you wrote:> Justin Carlson wrote:
> > Not if you want to have constant-defined offsets into the table.  Which is just
> > about the only reason to use a table for this...Either:
> > 
> 
> No, I am thinking to have constant-defined offset into the table.  Instead, I
> am thinking to do a linear search of the table and find a matching entry based
> on the PRID.
> 
> Without table, I can see two alternatives, 1) switch/case statement to fill in
> the data by statements (which is the current case) or 2) for each CPU
> (protected by #ifdef CONFIG_) we define a mips_cpu struct.
> 
> I guess I just like table better than switch/case statements.  Table seems
> cleaner to me.

You're not going to get rid of the big switch statement for older (non mips32)
processors because of the specialized checks to refine steppings, etc. 
as it is. 

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.    

Luckily, in the end, you have to convince saner people than me.  :)

-Justin

Re: broken RM7000 in CVS

[Jun Sun]

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

Ahh, in that case I suppose the mips_cpu_config function pointer in that entry
should not be NULL.  Instead it should modify the mips_cpu struct to fix
whatever quirks there.  Because this function is associated with a particular
CPU, this solution is probably cleaner than having all the quirk fixes
embedded inside a case block.

> 
> Luckily, in the end, you have to convince saner people than me.  :)
> 

Or I should wake up from hallucination.  :-)

Jun

Re: broken RM7000 in CVS

[Geert Uytterhoeven]

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.

Gr{oetje,eeting}s,

						Geert

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

Re: broken RM7000 in CVS

[Jun Sun]

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

Re: broken RM7000 in CVS

[Geert Uytterhoeven]

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.

Gr{oetje,eeting}s,

						Geert

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