This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [Revised patch] Rework MIPS command-line handling
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: cgd at broadcom dot com
- Cc: gcc-patches at gcc dot gnu dot org, binutils at sources dot redhat dot com,"Thiemo Seufer" <ica2_ts at csv dot ica dot uni-stuttgart dot de>,"Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>,"Eric Christopher" <echristo at redhat dot com>,"Mark D. Baushke" <mdb at gnu dot org>
- Date: 19 Jul 2002 09:36:11 +0100
- Subject: Re: [Revised patch] Rework MIPS command-line handling
- References: <wvnfzyodh02.fsf@talisman.cambridge.redhat.com><wvnofd46duh.fsf@talisman.cambridge.redhat.com><yov5u1mwsr66.fsf@broadcom.com>
cgd@broadcom.com writes:
> > Question is, what are right values for _MIPS_ARCH and _MIPS_TUNE when
> > you use a generic ISA? It doesn't seem right for them to name a
> > processor when the command line and configuration don't specify one.
>
> I would advise simply going with whatever the processor is, unless
> you're going to create 'real' entries for the arches
> (e.g. _PROCESSOR_MIPS1.)
OK, if no-one jumps in, that's what I'll do.
> > Not the biggest issue, I know, but is _MIPS_<foo> OK for the
> > processor macros? I guess other alternatives would be
> > _MIPS_PROCESSOR_<foo> or _PROCESSOR_<foo>.
>
> I'm for _PROCESSOR_*.
Others thought so too, so OK.
> I don't see why the values shouldn't change.
>
> (1) The numbers aren't really meaningful.
>
> (2) if used properly (as outlined in my message which spawned this
> particular feature), they'll all be resolved at compile time.
>
> If there's a desire to record the values, e.g. for diagnostic output
> from programs, that should probably be done using defines that use
> strings.
Well, string macros are no problem, so I can add _MIPS_ARCH_STRING
and _MIPS_TUNE_STRING. If there really is no need for the macros
to have guaranteed values, then there's obviously no need for a
numbering convention, but...
> I've outlined (in off-list mail) a mechanism that would allow code to
> check for specific CPUs being used in arch/tune which doesn't involve
> any of this persistent, ad hoc numbering crud. I think it's the right
> way.
>
> For the benefit of everybody else:
>
> assume the processors _PROCESSOR_FOO and _PROCESSOR_BAR are
> used by _MIPS_ARCH and _MIPS_TUNE
>
> define _PROCESSOR_FOO the value 1.
>
> iff FOO != BAR, define _PROCESSOR_BAR the value 2.
>
> Since CPP math treats undefined values as 0, code like:
>
> #if (_MIPS_ARCH == _PROCESSOR_LALALA)
>
> will work properly, and code written as the example in my orignal
> message:
>
> switch (_MIPS_ARCH) {
> #ifdef _PROCESSOR_LALALA
> case _PROCESSOR_LALALA:
> ...
> break;
> #endif
> default:
> ...
> break;
> }
>
> will also work properly.
>
> I believe that those are good examples of the style with which these
> new defines should be used.
It seems counter-intuitive to me that a condition written using '=='
should only be usable in preprocessor statements. Many style guides
ask you to use C conditions instead of preprocessor ones, but you
wouldn't be able to write:
if (_MIPS_ARCH == _PROCESSOR_LALALA)
...
There's also the chance of subtle errors, like:
int optimize_for = _MIPS_TUNE;
and, in another file, perhaps part of a library:
switch (optimize_for)
{
#ifdef _PROCESSOR_LALALA
case _PROCESSOR_LALALA:
...
#endif
}
OK, it obviously wouldn't be supported under the _MIPS_TUNE == 1 or 2
scheme, but it would compile, and having '_MIPS_TUNE == FOO' conditions
might just lead people to believe that _MIPS_TUNE can be treated as a
regular number (like __mips or __mips_fpr can).
The optimiser will (ought to?) remove redundant code, so why force
the user to wrap each case in '#ifdef's? Why not allow...
switch (_MIPS_ARCH)
{
case _PROCESSOR_LALALA:
...
}
And if we define all the _PROCESSOR_FOO macros for each compilation
unit, we might as well try to give them lasting values...
If that idea really doesn't fly, I'd rather have _MIPS_ARCH
be a string and define _MIPS_ARCH_FOO when compiling for FOO.
Richard