Maciej Rozycki <maciej.rozy...@imgtec.com> writes: > On Thu, 5 Jan 2017, Matthew Fortune wrote: > > It is true to say that users are discouraged from using 2008-NaN with > > soft-float for pre-R6 architectures simply to avoid further fragmentation > > of software for no real gain. However, for R6 then soft-float is 2008-NaN > > otherwise we are stuck with legacy-NaN forever. > > What's the actual issue you have with legacy NaN, and how does soft-float > relate to R6? It's not like hardware, R6 or othwerwise, limits soft-float > in any way.
What about floating point data stored in binary form written by a hard-float app and read by a soft-float etc. From R6 onwards it would be poor not to address this and make it the same. I assume people do this sometimes! For R5 I agree there is no useful reason to do soft-float in nan2008 but someone may wish to do that in a closed environment if perhaps they have a requirement like the one I describe above for R6. > > If someone did want to build a system from source with soft-float as > > 2008-NaN then I see no reason to stop them but I doubt they would and I > > don't expect the --with-nan GCC configure option to be used in conjunction > > with --with-float=soft for the same reason. The most likely use of > > --with-nan is to build a distribution specifically to target an MSA capable > > system like P5600 or perhaps an M5150 with an FPU. The NaN interlinking > > work will make these use-cases less important still though I think. > > You can have GCC configured with `--with-nan=2008' and equipped with a You 'can' but I don't think you would... unless that is actually what you wanted which is really the premise of permitting nan2008 soft-float. > soft-float multilib. IMHO you ought to be able to just use `-msoft-float' > then to select the soft-float multilib and have it implicitly use the > legacy NaN encoding rather than having to pass `-msoft-float -mnan=legacy' > to get the intended semantics. This is something a vendor configuration could handle or the addition of a spec to do it but I believe we have currently got a reasonably clean separation of options in the generic/unknown configuration such that use of one option does interfere with others (at least in terms of the options which affect which ABI variant is in use). The less x implies y type options we have the less mental trauma we have in understanding what the effective behaviour is of a given set of options. That's not to say it is in any way easy to figure out currently from an arbitrarily selected MIPS GCC toolchain. > There shouldn't be a need for NaN interlinking for soft-float objects, > that's just unnecessary burden IMO. Indeed. I can't see anyone needing that as soft-float nan-2008 version is highly unlikely. > MSA is irrelevant for soft-float operations, we don't have a soft-float > MSA ABI. If we ever define one, then we could well choose the 2008-NaN > encoding for compatibility with hard-float code; there's no issue with > backwards compatibility here as no legacy-NaN MSA hardware has been ever > allowed. I wasn't meaning to imply MSA makes sense with soft-float but rather making the point that there are few scenarios where --with-nan configure time option is likely to be used but one is a hard-float MSA native toolchain. > Have I missed anything? Summary: * No technical need to prohibit nan2008 soft-float * Benefit to R6 onwards such that we don't have to track two different floating point formats forever in tools that may not bother with pre-r6 in the future. * Marginal benefit in sharing floating point data in binary format between soft and hard float programs. Hope that explains my thinking on this. Matthew
