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

[cgd at broadcom dot com]

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



cgd