[PATCH] MIPS: IEEE 754-2008 NaN encoding features
Maciej W. Rozycki
macro@codesourcery.com
Sat Dec 8 12:54:00 GMT 2012
More information about the Binutils mailing list
Sat Dec 8 12:54:00 GMT 2012
- Previous message (by thread): [PATCH] MIPS: IEEE 754-2008 NaN encoding features
- Next message (by thread): [PATCH] MIPS: IEEE 754-2008 NaN encoding features
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 8 Dec 2012, Richard Sandiford wrote: > > As many of you have been aware it has been a long practice for software > > using IEEE 754 floating-point arithmetic run on MIPS processors to use an > > encoding of Not-a-Number (NaN) data different to one used by software run > > on other processors. And as of IEEE 754-2008 revision this encoding does > > not follow one recommended in the standard, as specified in section 6.2.1, > > where it is stated that quiet NaNs should have the first bit (d1) of their > > significand set to 1 while signalling NaNs should have that bit set to 0, > > but MIPS software interprets the two bits in the opposite manner. > > > > An upcoming MIPS Architecture revision will provide for processors that > > support the IEEE 754-2008 preferred NaN encoding format. As the two > > formats (further referred to as "legacy NaN" and "2008 NaN") are > > incompatible to each other, tools will have to provide support for the two > > formats to help people avoid using incompatible binary modules. Here is > > the binutils part. > > > > Two new entities have been added to support static and dynamic linking. > > For the former a set of new ELF file attribute values have been defined. > > For the latter a new ELF file header flag has been defined. These changes > > are described in detail below. > > But an ELF flag supports static and dynamic linking on its own. > Encoding the same information in the attribute seems redundant, > and makes the implementation a fair bit more complicated. Sources need to be annotated as NaN encodings will be present within them -- .gnu_attribute is suited for this purpose. The header flag is required so that the kernel configures the FPU appropriately or rejects binaries that are incompatible with hardware being used that does not support the NaN encoding requested and also so that ld.so refuses to load incompatible modules together. Do you have any better proposal? I can drop the setting on the header flag on relocatables and keep it on final binaries only if that made you feel better. Maciej
- Previous message (by thread): [PATCH] MIPS: IEEE 754-2008 NaN encoding features
- Next message (by thread): [PATCH] MIPS: IEEE 754-2008 NaN encoding features
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list