This is the mail archive of the
binutils@sourceware.org
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>, echristo at apple dot com
- Cc: Richard Sandiford <rsandifo at nildram dot co dot uk>, binutils at sourceware dot org
- Date: Thu, 06 Mar 2008 11:21:35 -0800
- Subject: Re: [PATCH, MIPS] Add support for CPUs with no FPU
- References: <18358.7414.677959.951389@localhost.localdomain> <87odahz5zx.fsf@firetop.home> <18359.13687.499896.866572@localhost.localdomain> <20080217015527.GB4747@networkno.de> <18360.34888.459621.368358@localhost.localdomain> <87fxvmkig9.fsf@localhost.localdomain.i-did-not-set--mail-host-address--so-tickle-me>
Ping.
On 2/20/08, Adam Nemet wrote:
> Thiemo,
>
> 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
> friends.
>
> Adam
>
> Adam Nemet <anemet@caviumnetworks.com> 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.
>>
>> Adam