This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Revised patch] Rework MIPS command-line handling


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]