This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, MIPS] Add support for CPUs with no FPU
- From: Adam Nemet <anemet at caviumnetworks dot com>
- To: Thiemo Seufer <ths at networkno dot de>
- Cc: echristo at apple dot com, Richard Sandiford <rsandifo at nildram dot co dot uk>, binutils at sourceware dot org
- Date: Thu, 13 Mar 2008 11:46:13 -0700
- Subject: Re: [PATCH, MIPS] Add support for CPUs with no FPU
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20080217015527.GB4747@networkno.de> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On 3/06/08, Adam Nemet wrote:
> On 2/20/08, Adam Nemet wrote:
>> Do you have other concerns or the explanation below answers your question? If
>> yes I'd like to resubmit patch with the main change that the fp default would
>> be set up by configure similarly to MIPS_DEFAULT_ABI instead of -march and
>> Adam Nemet <firstname.lastname@example.org> writes:
>>> 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.