This is the mail archive of the
mailing list for the binutils project.
Re: [Revised patch] Rework MIPS command-line handling
At Fri, 19 Jul 2002 02:53:39 -0700, Mark D. Baushke wrote:
> I like the idea of 'real' entries for the known existing mips and
> mips-like processors.
But, defined where? 8-)
> > > 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.
> Strings are nice. In a big memory machine, they are a fine thing to use.
> When you have limited space they can be unfriendly, else why does the
> -mips16 instruction set exist?
well, re: the latter, I'm sure you could get differing opinions by
asking a few people. 8-)
Are the things that use -mips16 likely to want to spend the space on
multi-arch/multi-tune configuration in the same set of binaries? If
not (and I think the answer is not ... else why use them to begin
with?), then the size of the strings for them is irrelevant.
> > 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.
> Well, the use of long strings that might show up multiple times in the
> text or data segments of a program can be painful to the embedded world
> who seems to always need more space to fit everything onto the device,
> so care would be needed if that path was chosen to keep the names of
> reasonable length if possible.
(1) not long strings. 8-)
(2) strings shouldn't show up often -- if at all, only in a few the
'configure the optimized routines' fns/args/globals. I.e., if
you're doing string, or even integer, comparison often, it's
likely you've lost the benefit of using optimized routines to