Re: RFC & patch: Rework MIPS command-line handling

[cgd at broadcom dot com]

At Mon, 15 Jul 2002 11:51:11 +0000 (UTC), "Richard Sandiford" wrote:
> > > + /* This array must have the same order as enum processor_type.  */
> > > + static const struct mips_processor mips_processors[] = {
> > > +   { "default", 0, 1 },
> > > +   { "r3000", "_R3000", 1 },
> > > +   { "r3900", "_R3900", 1 },
> > > +   { "r6000", "_R6000", 2 },
> > > +   { "r4000", "_R4000", 3 },
> > > +   { "vr4100", "_R4100", 3 },
> > > +   { "vr4300", "_R4300", 3 },
> > > +   { "r4600", "_R4600", 3 },
> > > +   { "r4650", "_R4650", 3 },
> > > +   { "vr5000", "_R5000", 4 },
> > > +   { "r8000", "_R8000", 4 },
> > > +   { "r4kc", "_R4KC", 32 },
> > > +   { "r5kc", "_R5KC", 64 },
> > > +   { "r20kc", "_R20KC", 64 }
> > > + };
> > 
> > OK, assuming that i'm seeing all of the uses of these, disagree on a
> > couple of grounds:
> > 
> > * some of these are things which implementations (i.e., existing
> >   systems) may have already come to define.  IMO they need more
> >   letters.
> 
> I took my cue from R3000 and R4000, which were the standard before.

So, historically, those defines _seem_ to be used less as 'processor'
defines and more as 'GPR size' defines, at least looking at the way
GCC defined them in say 3.0.x.


> The table is just a mindless extension to the other processors.
> How about zeroing out any macro entries that aren't appropriate?

Well...

Nobody expects the new defines, something better seems like it would
be worthwhile (rest of msg), and I'd _guess_ (not knowing for sure)
that code which uses _R3000 & _R4000 do so expecting them to indicate
GPR size...

So, really, I'd just the define names in that table and leave _R3000
and _R4000 alone.

I don't know what code actually depends on those defines... but in a
perfect world, I think we'd nuke them.  8-)  Maybe make it possible for
OSes to kill those backward-compatibility defines, so that OSes which
want to clean up their define space can do so.



cgd