RFC & patch: Rework MIPS command-line handling

[cgd@broadcom.com]

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


> I'd prefer to choose the default CPU in configure: that way, we'd
> get a compile-time error over missing entries, plus we can use globs.

yay.


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

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.


some specific comments about the patch:

i didn't really look carefully at the gas changes.  I suspect that
they'll break our firmware like the last set of ABI-related changes
did, but, well, assuming they pass all of the existing test cases (w/
the one changed as you did), it shouldn't be too bad.  8-)


> ! @item -mips32
> ! @opindex mips32
> ! Equivalent to @samp{-march=r4kc}.
>   
> ! @item -mips64
> ! @opindex mips64
> ! Equivalent to @samp{-march=r5kc}.

again, the proper names of these cores as far as i'm aware (see MIPS
web pages) are MIPS32 4Kc and MIPS64 5Kc.  I.e., the 'r' is really
truly incorrect here, unlike for the R4000 which was really called the
R4000.

(same for 20kc, btw.)


> + /* 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.

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


So long as you avoid 0, this allows you to do useful, sane things,
e.g.:

	#if ((_MIPS_ISA == 4) || (_MIPS_ARCH == _PROCESSOR_SPECIAL)) && \
	    (_MIPS_TUNE != _PROCESSOR_BROKEN)

and:

	switch (_MIPS_TUNE) {
#ifdef _PROCESSOR_X
	case _PROCESSOR_X:
		asm(...);
		break;
#endif
#ifdef _PROCESSOR_Y
	case _PROCESSOR_Y:
		asm(...);
		break;
#endif
	default:
		unoptimized_code();
		break;
	}

Personally, I find that to be a prettier and _much much more useful_
idiom than something _MIPS_ARCH_FOO, _MIPS_TUNE_FOO.

Finally, for the 'print a number but don't necessarily say what it is'
crowd, it lets you encode the arch/tune values in the program in a
fail-safe way that a code builder w/ the compiler source can later use
(e.g. after a bug report) to figure out which arch/tune was used.
(can't do that with _MIPS_ARCH_FOO, since what if the one that's
define is one you don't know about.  with something like described
above, it's always an integer.)

In any case, you really do need longer names for most of those IMO.


> + /* Return true if GIVEN is the same as CANONICAL, or if it is CANONICAL
> +    with a final "000" replaced by "k".  Ignore case.

Oi, this is really going to exacerbate 4kc vs r4k problems if you
allow the 4kc to be called the r4kc!


I may have missed some things, too.  8-)



chris