[RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

[Maciej W. Rozycki]

Hi Matthew,

 I'm back to this effort now, thanks for patience.

> Thanks for the update.  I've read through the whole proposal again and
> it looks good.  I'd like to discuss legacy objects a bit more though...

 Thanks for your review.

> > 3.4 Relocatable Object Generation
> > 
> >  Tools that produce relocatable objects such as the assembler shall
> > always produce a SHT_MIPS_ABIFLAGS section according to the IEEE Std 754
> > compliance mode selected.  In the absence of any explicit user
> > instructions the `strict' mode shall be assumed.  No new `legacy'
> > objects shall be produced.
> 
> Is it necessary to say that no new legacy objects can be created?

 It is of course not necessary in the sense that we are free to make a 
decision here rather than being constrained by hardware or another 
technical requirement.

 However I think only supporting the two explicit `strict' and `relaxed' 
modes makes the solution proposed consistent, and has indeed been the 
basis of my design.

 The principle I have followed here has been that it's the author of 
software who knows exactly what his code requires for correct operation, 
and sets the correct flags in the Makefile or whatever build system he 
uses.  Joseph's earlier proposal to have a generic `-fieee' option rather 
than a target one fits here very well in that the author can stick it in 
the build system without the exact knowledge of what target-specific 
constraints may be.  Such an option would preferably be placed such that 
it is not accidentally lost e.g. with an OS distribution packager's CFLAGS 
override, which is typically made in a system-wide automated way when a 
distribution is build.

 Still a distribution packager or another person building their piece of 
software of interest, perhaps individually, has control here, being able 
to change build options one way or another, at least by patching Makefiles 
if necessary.  So they can choose `strict' or `relaxed' as needed.

 Finally the system administrator configuring a system or the individual 
user running software has the least knowledge of the low-level 
requirements of individual pieces of software.

 So ideally we'd not even have these kernel override modes and 
unconditionally treat `legacy' binaries as `strict', under the principle 
of the least surprise.  Realistically however that would make the 
transition to R5/R6 very painful for people, requiring them to rebuild all 
software previously built for the legacy NaN encoding, even though only a 
small subset of software actually relies on the semantics of signalling 
NaNs.

 And this is exactly where the idea of a user-selectable kernel acceptance 
mode came from.  I expect that both existing and new installations on 
legacy-NaN hardware will continue operating with the `strict' conformance 
mode and won't ever have to switch that as any new software built for 
pre-R5 targets and with the 2008-NaN encoding in mind will be built as 
`relaxed' binaries.  Whereas virtually all R5/R6 installations will run in 
the `relaxed' conformance mode, permitting the use of any existing pre-R5 
`legacy' binaries, however with the risk of some of them producing the 
wrong results.

 Consequently allowing new tools to build more `legacy' binaries will just 
let the issue continue where the mode software being run in depends on the 
hardware configuration rather than a conscious choice of the software 
packager.  Whereas support for running `legacy' binaries in the `relaxed' 
mode is really there to help people transition.

> I think there is value in still being able to generate legacy objects because
> of the fact that strict executables leave no room for override at runtime.
> Apart from the fact that strict cannot be disabled there is otherwise no
> difference between legacy and strict compliance modes.

 Can you please be more specific?  Where's the value from letting people 
override the mode of software known to require signalling NaN support?

> I believe the strict option is really intended for conscious use so that
> programmers who know they need it, can use it. Ordinary users still get the
> casual safety they need as legacy objects are just as good as strict until
> overridden. If we lose the ability to override then in some environments we
> will accumulate lots of needlessly strict executables just because of a tools
> upgrade whereas the old tools would have generated executables that were as
> safe but also could be overridden by kernel options. 

 I think the casual safety is an illusion.

 As soon as a user gets an execution error from a legacy-NaN legacy binary 
on 2008-NaN hardware (or vice versa), they'll hit Google or discussion 
list archives for a solution, find the `ieee754=relaxed' kernel option, 
stick it into their bootloader configuration and forget about it, running 
all their software from the on in the `relaxed' mode anyway.

 Eventually distributions will probably do that as well even if they built 
their own packages as `relaxed', to reduce support noise from people 
running `legacy' third-party software built for the opposite NaN encoding.

 Now, assuming that their software is indeed safe for `relaxed' mode 
operation with the binary `strict'/`relaxed' choice available you have 
valuable information carried within binaries themselves -- they tell you 
whether they care about signalling NaN interpretation or not rather than 
maybe/maybe-not.

> Allowing legacy objects to be generated may also allow the linkage rules to
> be tightened.  I.e. Forcing a relaxed mode at link time could simply fail
> if confronted by a strict object instead only allowing legacy objects to
> be relaxed.

 We can still have a mode where a `strict' object is rejected in a static 
link.  Though I'm not sure if there's value in it.  If so, then perhaps we 
need a `never relax' flag instead.  Do you have a specific use case in 
mind?

> A default build of GCC and binutils would therefore still generate legacy
> objects until someone consciously updated the configure options or used
> command line options.
 
 As I've argued above I'm inconvinced that keeping the `legacy' mode 
supported for newly built binaries is a good idea.  If you're concerned 
about software being built as `strict' unnecessarily, then I think we have 
two solutions here:

1. We can default the toolchain configuration to the `relaxed' (or 
   strictly speaking the `relaxed-exec') mode.  This way someone upgrading 
   their OS from sources will not fall into a trap of building their 
   software as `strict' by the lone result of missing the required 
   newly-added configuration option, rather than a conscious decision.  I 
   think this would be a reasonably safe move, as a signalling NaN support
   requirement is I believe relatively uncommon across software.

2. An idea has been proposed to have objects marked by the assembler to 
   indicate whether they include an FP hardware instruction or not.  The 
   latters would automatically become don't-cares as far as NaN encoding
   is concerned and if all the objects were such in a given static link, 
   then the resulting executable would become NaN-encoding agnostic, 
   ignoring any `strict' or `relaxed' modes.  This would exclude a large
   amount of software from the checks discussed in this specification,
   although a question still remains open how shared libraries loaded by 
   such a program would be treated if they for a change did include FP
   hardware instructions.

Does either of the proposals address your concerns?  Is there anything I 
may have missed here?

 I will appreciate input from other people as well, so that it's not a 
discussion just between Matthew and myself.  Joseph, does your experience 
in this area give you any insights?

  Maciej