This is the mail archive of the binutils@sourceware.org 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: [PATCH, MIPS] Add support for CPUs with no FPU


Thiemo Seufer writes:
> > I agree that new behavior might be somewhat surprising on the more generic
> > config targets.  I'm certainly fine with keeping soft-float independent of the
> > CPU target assuming that we still have the option of building a soft-float
> > defaulted assembler for particular target configurations
> > (e.g. mips64octeon*-*-*).
> 
> What problem does this solve? IME calling as/ld directly is a pain to
> get right and maintain, using them via the gcc driver is superior (with
> some exceptions like bootloader asm files).

In our experience there are lots of users (typically developers who get their
toolchains from CPU vendors) that expect the toolchain to give the most help
in their work for that particular CPU.  I don't think I need to stress the
value of being able to diagnose situation at the compile time that are
guaranteed to fail at run time.  As I said in my previous email I don't have a
problem if a "generic" MIPS toolchain won't default to soft-float if one
switches to Octeon with -march=octeon but I do believe that a toolchain built
specifically for Octeon should reflect the Octeon programming model in all
user-visible components.

And unfortunately people do use as and even ld directly.  as and ld have man
and info pages, are used in the built-in implicit rules in GNU make, etc.

I guess regardless of whether soft-float and singe-float are considered to be
a CPU property or an ABI property, there is already existing practise to add
defaults for either in gas.  r4650 is defaulting to single-float and there is
MIPS_DEFAULT_ABI in configure that let you set the default ABI based on the
target.  It is probably not as sophisticated as GCC's -with- mechanism from
the toolchain developer perspective but it is *equally* useful from a
toolchain user's perspective.

Needless to say this patch is much less valuable for us if this cannot be the
default for Octeon.  The default helps precisely the people who are least
likely to know about the -msoft-float option whereas people who are
knowledgeable enough and decide to use kernel FPU emulation on a soft-float
target are likely to have also learned about -mhard-float.

I still hope we can find a compromise here.

Adam


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