RFC & patch: Rework MIPS command-line handling

[Richard Sandiford]

cgd@broadcom.com writes:
> At Fri, 12 Jul 2002 17:04:01 +0000 (UTC), "Richard Sandiford" wrote:
> > - GAS and GCC didn't have quite the same -march arguments.  For
> >   example, GCC accepts -march=r4kc, but GAS insists on -march=4kc.
> >   To avoid that sort of thing in future, I've written a function
> >   that tries all the variations, using a table of just the
> >   "canonical" names.
> 
> accepting "r4kc" etc., would appear to be a bug w/ with GCC
> implementation.  I wouldn't suggest propagating it, since it does
> cause confusion with "r4000" (which people think of as 'r4k').

OK.  I'll do it the other way round then, and stop gcc accepting
the 'r4kc', etc.

> > Before 2.12, we only set EF_MIPS_ABI when -mabi was given on
> > the command line.  Since EF_MIPS_ABI is a GNU extension, the
> > onus seems to be on proving that it's safe to use it by default,
> > rather than the other way about.  So the patch uses NO_ABI as
> > the default for all configurations, but leaves open the possibility
> > of setting the default to something else on a per-configuration
> > basis.
> 
> So, in the absence of EF_MIPS_ABI, what is a sane, compact code
> fragment which will reliably determine which ABI is in use?  It's
> important to have such a thing.

I hope the patch at least makes things better: gcc will never implicitly
choose an ABI except when switching between 32-bit and 64-bit code
generation.  So objects compiled with the same gcc are likely to be OK.
Not strong enough, I know, but even that isn't guaranteed at the moment.

> There's still an argument to be had which says "nobody else is doing
> the right thing here, if we need binary ABI marking we should do it
> and encourage others to follow suit," e.g. has happened w/ the arch
> markings.

The original idea was to turn the ABI flags on for specific targets
(as and when it seemed safe).  I guess one way of forcing the issue
would be to use them by default, but turn them off for configurations
that really don't want them.  There'd need to be some easy way of
unsetting an object's ABI flags.

> > + /* 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.
The table is just a mindless extension to the other processors.
How about zeroing out any macro entries that aren't appropriate?

> * we should also be providing a predefine for tune.  Ideally what i'd
>   like to see is something like:
> 
> 	_MIPS_ARCH=_PROCESSOR_FOO
> 	_MIPS_TUNE=_PROCESSOR_BAR
> 
>   then internally define _PROCESSOR_FOO and _PROCESSOR_BAR to have
>   unique numbers internally and only add as defines the ones which are
>   used.

I like it.  Probably a separate patch, though.  I'll try to come
up with something once the options stuff is over with.

Richard