* [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-14 10:42 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-14 10:42 UTC (permalink / raw
To: linux-mips, libc-alpha, binutils, gcc
Cc: Matthew Fortune, Daniel Sanders, Leonid Yegoshin
Dear fellow developers,
On behalf of Imagination Technologies I would like to introduce the
following ABI extension to create a compatibility solution for opposing
NaN encodings. I will appreciate your feedback and will happily answer
any questions and address any concerns you may have.
A copy of this document has been also posted at:
https://dmz-portal.mips.com/wiki/MIPS_ABI_-_NaN_Interlinking
and will be considered the master reference.
I have a prototype implementation available, spanning the Linux kernel,
the dynamic linker component of the GNU C Library, GNU Binutils and GCC,
proving the correctness of this specification. At this point it has
passed manual testing and I will be posting patches shortly, to the
relevant mailing lists, as a reference. Ultimately the implementation
will be updated according to any changes to the specification made in the
review initiated here.
And last but not least I would like to thank Matthew Fortune, Daniel
Sanders and Leonid Yegoshin for their invaluable input in preparing this
specification.
Maciej
--------------------------------------------------------------------------
MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
1. Introduction
The MIPS architecture has supported IEEE Std 754 floating-point
arithmetic since its beginning in 1985. Naturally as initial support was
for the original 1985 revision of the standard then particular choices
were made for the architecture where freedom was given by that revision.
This was the case with not-a-number (NaN) symbolic data and the bit
patterns chosen to represent them. Later on this choice turned out to be
different from ones used by all other IEEE Std 754 implementers. Hardware
implementing this original MIPS architecture definition and corresponding
software and ABIs will be referred across this document as legacy-NaN
hardware, software and ABIs respectively, and the NaN patterns themselves
as legacy NaN patterns.
The patterns originally chosen had their advantage in the MIPS
architecture, however an updated revision of IEEE Std 754 released in 2008
made the NaN patterns chosen by other implementers preferred. MIPS
architecture overseers decided to follow the recommendation and update the
architecture definition accordingly. Consequently a set of amended ABIs
has been created to provide for software execution on hardware
implementing the updated architecture. Such hardware, software and ABIs
will be referred across this document to as 2008-NaN hardware, software
and ABIs respectively, and the NaN patterns themselves as to 2008 NaN
patterns.
The legacy and 2008 NaN patterns are not compatible with each other and
therefore the respective ABIs and software binaries are not. To keep all
software compliant to IEEE Std 754 a decision was made to disallow mixing
legacy-NaN and 2008-NaN software modules in static linking and dynamic
loading, and at the OS level disallow execution of 2008-NaN software on
legacy-NaN hardware and vice versa.
2. Statement of the Problem
The decisions made so far about the MIPS architecture and ABIs have led
to a situation where the large existing base of software binaries cannot
execute on current hardware. And this applies regardless of whether it
relies on the use of NaN data or IEEE Std 754 arithmetic in the first
place. Rebuilding all of the existing software for 2008-NaN hardware is
infeasible and additionally such software, rebuilt or new, will not run on
legacy-NaN hardware that is widely deployed, so maintaining two binary
versions of the same piece of software would often be required.
3. Solution
The solution described here has been prepared with the Linux environment
in mind, although where applicable individual changes are also appropriate
for bare-metal environments.
A number of changes are made at different levels to make the transition
to 2008-NaN hardware easier as well as long-term support for legacy-NaN
hardware that is undoubtedly going to stay around for a while. They are
detailed from the hardware level up in the following sections.
3.1 Hardware and Operating System Interface
The operating system tells legacy-NaN and 2008-NaN software apart by
examining the state of the EF_MIPS_NAN2008 flag in the ELF file header of
individual binaries requested for execution with the execve(2) system
call. The value of `0' of the flag denotes legacy-NaN software and the
value of `1' denotes 2008-NaN software.
3.1.1 Floating-Point Emulation
Where possible both legacy-NaN and 2008-NaN software will be supported.
The MIPS architecture itself makes it possible and therefore the FPU
emulator used on hardware that does not implement an FPU will set itself
to the right mode individually for every legacy-NaN or 2008-NaN program
executed.
On Linux the FPU emulator can also be enabled unconditionally even on
hardware that does implement an FPU, with the use of the `nofpu' kernel
option. In this case both legacy-NaN and 2008-NaN software will be
automatically supported, although at a performance loss compared to FPU
hardware.
3.1.2 Global IEEE Std 754 Compliance Mode
A new `ieee754=' kernel option is provided for cases where strict IEEE
Std 754 compliance is not required. This makes it possible to use
binaries from existing Linux distributions on new 2008-NaN hardware making
the transition easier. At least two values are accepted on the right hand
side of this option, `strict' and `relaxed', to select between IEEE Std
754 compliance modes. These modes shall only affect software that does
not make an explicit mode selection as noted in Section 3.1.3 below.
In the `strict' mode, which is the default in the absence of an explicit
`ieee754=' option, only software compatible with the NaN patterns handled
by FPU hardware shall be accepted for execution, that is legacy-NaN
software on legacy-NaN hardware and 2008-NaN software on 2008-NaN
hardware.
In the `relaxed' mode any software shall be accepted for execution,
regardless of whether it is compatible with FPU hardware. Additionally,
in the `relaxed' mode, even if enabled with the FCSR.Enables.V bit, any
IEEE Std 754 Invalid Operation exceptions triggered with an sNaN
instruction operand shall not result in a SIGFPE signal being issued to
the originating process and a qNaN (encoded according to the current mode
set in the floating-point environment) shall be substituted and propagated
through the arithmetic operation requested as with a qNaN operand.
Additionally, to make the dynamic loader aware that the `relaxed' IEEE
Std 754 compliance mode is in effect, bit #25 shall be set in the `a_val'
member of the AT_FLAGS entry of the auxiliary vector created by the
kernel on program execution for any program accepted for this mode. This
bit is in the part of the flag word reserved for system semantic by the
MIPS psABI[1]. This bit shall be set to `0' in the `strict' mode and `1'
in the `relaxed' mode.
Additional values may be accepted with the kernel option and consequently
modes provided now or in the future, but they are beyond the scope of this
document.
3.1.3 Per Program Individual IEEE Std 754 Compliance Mode
Individual programs can select their required IEEE Std 754 compliance
mode regardless of the global mode. Individual selection takes precedence
over the global selection. Programs that select their individual mode
shall have a PT_MIPS_ABIFLAGS segment and shall have bit #1 set in its
`flags1' member. The specific mode selected is then determined by the
value of bit #1 in this segment's `flags2' member, `0' for the `strict'
mode and `1' for the `relaxed' mode.
The semantics of such individually selected IEEE Std 754 compliance
mode is the same as that of the corresponding global mode. See Section
3.1.2 above for further details.
3.1.4 Dynamic IEEE Std 754 Compliance Mode Control
A new request is provided via the prctl(2) system call to let a process
switch its own IEEE Std 754 compliance mode. This is for example to let
a dynamic loader invoked manually set the compliance mode for an
executable requested as if the executable was run directly and its
compliance mode preset by the kernel. The request shall be made as
follows:
int result;
result = prctl(PR_SET_IEEE754_MODE, mode, what);
In this request `mode' shall be set to one of the following:
* PR_IEEE754_MODE_LEGACY -- to set the compliance mode used with programs
which do not make an individual IEEE Std 754 compliance mode selection,
* PR_IEEE754_MODE_STRICT -- to set the `strict' compliance mode,
* PR_IEEE754_MODE_RELAXED -- to set the `relaxed' compliance mode,
and `what' shall be set to either of:
* PR_IEEE754_MODE_NAN_LEGACY -- to select the legacy-NaN encoding mode,
* PR_IEEE754_MODE_NAN_2008 -- to select the 2008-NaN encoding mode.
The kernel shall execute the request according to the rules set out in
Subsection 3.1.2 and Subsection 3.1.3 for the ELF file flag settings
corresponding to the respective IEEE Std 754 compliance and NaN encoding
modes requested.
If the request is successful a non-negative value shall be assigned to
`result', in which bits 7:0 are set to a pattern that would be placed in
bits 31:24, in the same bit order, of the `a_val' member of the AT_FLAGS
entry of the auxiliary vector created by the kernel on program execution
for the mode selected.
3.2 Dynamic Loading
The dynamic loader shall recognise IEEE Std 754 compliance modes and
resolve main executable's dependencies according to rules set below. For
the purpose of these rules a main executable is the binary named in an
execve(2) call to the operating system, and a dependency is any dynamic
shared object additionally loaded, via any means including but not
necessarily limited to a DT_NEEDED dynamic segment entry, an LD_PRELOAD
environment variable or a dlopen(3) library call.
3.2.1 IEEE Std 754 Compliance Mode Selection
Both executables and dynamic shared objects can select their required
IEEE Std 754 compliance mode. A binary requiring a specific compliance
mode shall have a PT_MIPS_ABIFLAGS segment and shall have its contents
set according to rules set out in Section 3.1.3. Such a binary will
be referred to as `strict' or `relaxed'. Binaries that have no
PT_MIPS_ABIFLAGS segment or have one that does not request a specific
compliance mode will be referred to as `legacy'.
3.2.2 Dynamic Dependency Acceptance Rules
The IEEE Std 754 compliance mode requested is determined by the main
executable. Any dynamic shared objects loaded in addition shall respect
the mode according to the rules set below.
For `strict' executables all the dynamic shared objects shall follow the
same legacy-NaN or 2008-NaN ABI, as denoted by the EF_MIPS_NAN2008 flag
described in Section 3.1. The value of the flag shall be the same across
the executable and all the dynamic shared objects loaded together. Both
`strict' and `legacy' dynamic shared objects shall be accepted, however
`relaxed' ones shall be rejected regardless of the value of their
EF_MIPS_NAN2008 flag.
For `relaxed' executables any dynamic shared objects shall be accepted,
`strict', `relaxed' and `legacy' alike, regardless of the value of their
EF_MIPS_NAN2008 flag.
For `legacy' executables the compliance mode is determined by the value
of bit #25 in the `a_val' member of the AT_FLAGS entry of the auxiliary
vector received from the kernel. The value of `0' shall make the dynamic
loader follow the rules for `strict' executables. The value of `1' shall
make the dynamic loader follow the rules for `relaxed' executables.
3.2.3 Dynamic Loading Compatibility Considerations
The encoding for the PT_MIPS_ABIFLAGS segment has been selected such that
old versions of the dynamic loader will reject `relaxed' binaries because
of an unknown `flags2' bit set. This is to prevent execution in an
environment that does not follow the rules set out in this specification
and to signify the need to upgrade. Both `strict' and `legacy' binaries
will run correctly as they follow the rules defined for old versions of
the dynamic loader.
Older versions of the dynamic loader will not process a PT_MIPS_ABIFLAGS
segment and will only examine the EF_MIPS_NAN2008 flag. Very old versions
of the dynamic loader will not even process the flag. It is therefore not
possible to guarantee that the rules set out here will be followed or an
error triggered with older systems.
3.3 Static Linking
The static linker shall recognise IEEE Std 754 compliance modes and
enforce the rules set below for all static links, both final ones that
produce an executable or a dynamic shared object and incremental ones
that produce a relocatable object.
3.3.1 IEEE Std 754 Compliance Mode Selection
All relocatable objects can select their required IEEE Std 754 compliance
mode. An object requiring a specific compliance mode shall have an
SHT_MIPS_ABIFLAGS section called `.MIPS.abiflags' and shall have its
contents set according to rules set out for the PT_MIPS_ABIFLAGS segment
in Section 3.1.3. Such an object will be referred to as `strict' or
`relaxed'. Objects that have no SHT_MIPS_ABIFLAGS section or have one
that does not request a specific compliance mode will be referred to as
`legacy'. On making an executable or a dynamic shared object the linker
shall map an SHT_MIPS_ABIFLAGS section to a PT_MIPS_ABIFLAGS segment.
3.3.2 Static Linking Object Acceptance Rules
The static linker shall follow the user selection as to the linking mode
used, either of `strict' and `relaxed'. The selection will be made
according to the usual way assumed for the environment used, which may be
a command-line option, a property setting, etc.
In the `strict' linking mode both `strict' and `legacy' objects can be
linked together. All shall follow the same legacy-NaN or 2008-NaN ABI, as
denoted by the EF_MIPS_NAN2008 flag described in Section 3.1. The value
of the flag shall be the same across all the objects linked together. The
output of a link involving any `strict' objects shall be marked as
`strict'. No `relaxed' objects shall be allowed in the same link.
In the `relaxed' linking mode any `strict', `relaxed' and `legacy'
objects can be linked together, regardless of the value of their
EF_MIPS_NAN2008 flag. If the flag has the same value across all objects
linked, then the value shall be propagated to the binary produced. The
output shall be marked as `relaxed'. It is recommended that the linker
provides a way to warn the user whenever a `relaxed' link is made of
`strict' and `legacy' objects only.
3.3.3 Static Linking Compliance Mode Warnings
A flag shall be defined in bit #0 of the `flags2' member of the
PT_MIPS_ABIFLAGS section, determining the warning mode for IEEE Std 754
compliance in static linking. This bit shall be set to `0' to enable
the warning mode (`warn' mode) and `1' to disable it (`nowarn' mode). The
bit shall propagate through an incremental static link in an
implementation-defined manner, however it shall be set to `0' in a final
static link.
3.3.4 Static Linking Compatibility Considerations
The encoding for the SHT_MIPS_ABIFLAGS section has been selected such
that old versions of the static linker will reject `relaxed' binaries
because of an unknown `flags2' bit set. This is to prevent incorrectly
annotated objects from being produced that would not guarantee IEEE Std
754 compliance.
The encoding has also been selected such that old versions of the static
linker will merge the `flags1' bit used to tell `legacy' objects and
`strict'/`relaxed' ones apart, automatically marking the output of links
involving any `strict' objects as `strict' as well.
Older versions of the static linker will not process an SHT_MIPS_ABIFLAGS
section and will only examine the EF_MIPS_NAN2008 flag. Consequently they
may allow `relaxed' objects in a single link with `strict' and `legacy'
ones.
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.
3.5 No-float Modules
Certain modules used in dynamic loading or static linking may be marked
as containing no floating-point code, in a way defined by a separate
specification. Such modules shall always be accepted for dynamic loading
and static linking, and for the purpose of IEEE Std 754 compliance checks
treated as if absent.
3.6 Definitions
The following macros shall be defined for the flags introduced by this
document:
/* `flags1' member of the PT_MIPS_ABIFLAGS/SHT_MIPS_ABIFLAGS structure. */
#define MIPS_AFL_FLAGS1_IEEE 2 /* IEEE Std 754 mode defined. */
/* `flags2' members of the PT_MIPS_ABIFLAGS/SHT_MIPS_ABIFLAGS structure. */
#define MIPS_AFL_FLAGS2_NOWARN 1 /* Suppress IEEE Std 754 warnings. */
#define MIPS_AFL_FLAGS2_RELAXED 2 /* Relaxed IEEE Std 754 mode. */
/* `a_val' member of the AT_FLAGS entry. */
#define AV_FLAGS_MIPS_RELAXED (1 << 25) /* Relaxed IEEE Std 754 mode. */
It is unspecified at this time whether the bits referred to with
MIPS_AFL_FLAGS2_RELAXED and AV_FLAGS_MIPS_RELAXED are single-bit bitfields
or the least significant bits of a larger enumeration, to be defined
later.
The following macros shall be defined for the prctl(2) interface
introduced by this document:
/* Control MIPS IEEE 754 compliance modes. */
#define PR_SET_IEEE754_MODE TBA
#define PR_IEEE754_MODE_LEGACY 0 /* Legacy mode. */
#define PR_IEEE754_MODE_STRICT 1 /* Strict mode. */
#define PR_IEEE754_MODE_RELAXED 2 /* Relaxed mode. */
#define PR_IEEE754_MODE_NAN_LEGACY 0 /* Set legacy NaN encoding. */
#define PR_IEEE754_MODE_NAN_2008 1 /* Set 2008 NaN encoding. */
4. Implementation Notes
For the GNU linker the command-line options to select between the
`strict' and the `relaxed' IEEE Std 754 compliance modes will be
`--ieee=strict' and `--ieee=relaxed', respectively. The latter will issue
a compliance warning in the case where all input objects were either
`strict' and `warn' or `legacy' mode, unless a `--ieee=nowarn' option has
also been used. There will be a `--ieee=warn' option as well to revert
the effect of the former option.
For the GNU assembler the directives to select between the `strict' and
the `relaxed' IEEE Std 754 compliance modes will be `.ieee strict' and
`.ieee relaxed', respectively. Equivalent command-line options will be
present, `-mieee=strict' and `-mieee=relaxed', respectively. There will
be `.ieee nowarn' and `.ieee warn' directives as well to set and clear
the IEEE Std 754 warning flag respectively in the SHT_MIPS_ABIFLAGS
section. Their corresponding command-line options will be `-mieee=nowarn'
and `-mieee=warn' respectively.
For the GNU Compiler Collection (GCC) the following command-line will be
accepted:
* `-mieee=strict', making the toolchain produce `strict' binaries,
* `-mieee=relaxed-exec', making the toolchain produce `strict' shared
libraries and `relaxed' executables,
* `-mieee=relaxed', making the toolchain produce `relaxed' binaries,
* `-mieee=force-relaxed', making the toolchain produce `relaxed' binaries,
while suppressing IEEE Std 754 static linking warnings.
It is expected that the two former options will be available as
configuration defaults to be selected at the GCC build time.
Any or all of these options may have effects beyond propagating the IEEE
Std 754 compliance mode down to the assembler and the linker. In
particular `-mieee=strict' is expected to guarantee code generated to
fully comply to IEEE Std 754 rather than only as far as NaN representation
is concerned.
There may be further GCC options to control IEEE Std 754 compliance, to
be defined.
5. Future Considerations
While at the time of this writing the `strict' and `relaxed' IEEE Std 754
compliance modes only apply to NaN representation patterns, it is possible
that in the future other IEEE Std 754 compliance matters may require
communicating through linking and loading down to the operating system
kernel. Therefore a decision has been made to use generic names for the
modes, macros, directives and option names defined here. If such a need
arises in the future, then the meaning of these names may be extended to
cover other compliance aspects and further modes can be added that are
intermediate between `strict' and `relaxed', to be used with the `.ieee'
directive and the `-mieee=' command-line options.
References:
[1] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
Supplement, 3rd Edition", Section "Process Stack", pp. 3-33, 3-34
^ permalink raw reply [flat|nested] 17+ messages in thread
* [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-14 10:42 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-14 10:42 UTC (permalink / raw
To: linux-mips, libc-alpha, binutils, gcc
Cc: Matthew Fortune, Daniel Sanders, Leonid Yegoshin
Dear fellow developers,
On behalf of Imagination Technologies I would like to introduce the
following ABI extension to create a compatibility solution for opposing
NaN encodings. I will appreciate your feedback and will happily answer
any questions and address any concerns you may have.
A copy of this document has been also posted at:
https://dmz-portal.mips.com/wiki/MIPS_ABI_-_NaN_Interlinking
and will be considered the master reference.
I have a prototype implementation available, spanning the Linux kernel,
the dynamic linker component of the GNU C Library, GNU Binutils and GCC,
proving the correctness of this specification. At this point it has
passed manual testing and I will be posting patches shortly, to the
relevant mailing lists, as a reference. Ultimately the implementation
will be updated according to any changes to the specification made in the
review initiated here.
And last but not least I would like to thank Matthew Fortune, Daniel
Sanders and Leonid Yegoshin for their invaluable input in preparing this
specification.
Maciej
--------------------------------------------------------------------------
MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
1. Introduction
The MIPS architecture has supported IEEE Std 754 floating-point
arithmetic since its beginning in 1985. Naturally as initial support was
for the original 1985 revision of the standard then particular choices
were made for the architecture where freedom was given by that revision.
This was the case with not-a-number (NaN) symbolic data and the bit
patterns chosen to represent them. Later on this choice turned out to be
different from ones used by all other IEEE Std 754 implementers. Hardware
implementing this original MIPS architecture definition and corresponding
software and ABIs will be referred across this document as legacy-NaN
hardware, software and ABIs respectively, and the NaN patterns themselves
as legacy NaN patterns.
The patterns originally chosen had their advantage in the MIPS
architecture, however an updated revision of IEEE Std 754 released in 2008
made the NaN patterns chosen by other implementers preferred. MIPS
architecture overseers decided to follow the recommendation and update the
architecture definition accordingly. Consequently a set of amended ABIs
has been created to provide for software execution on hardware
implementing the updated architecture. Such hardware, software and ABIs
will be referred across this document to as 2008-NaN hardware, software
and ABIs respectively, and the NaN patterns themselves as to 2008 NaN
patterns.
The legacy and 2008 NaN patterns are not compatible with each other and
therefore the respective ABIs and software binaries are not. To keep all
software compliant to IEEE Std 754 a decision was made to disallow mixing
legacy-NaN and 2008-NaN software modules in static linking and dynamic
loading, and at the OS level disallow execution of 2008-NaN software on
legacy-NaN hardware and vice versa.
2. Statement of the Problem
The decisions made so far about the MIPS architecture and ABIs have led
to a situation where the large existing base of software binaries cannot
execute on current hardware. And this applies regardless of whether it
relies on the use of NaN data or IEEE Std 754 arithmetic in the first
place. Rebuilding all of the existing software for 2008-NaN hardware is
infeasible and additionally such software, rebuilt or new, will not run on
legacy-NaN hardware that is widely deployed, so maintaining two binary
versions of the same piece of software would often be required.
3. Solution
The solution described here has been prepared with the Linux environment
in mind, although where applicable individual changes are also appropriate
for bare-metal environments.
A number of changes are made at different levels to make the transition
to 2008-NaN hardware easier as well as long-term support for legacy-NaN
hardware that is undoubtedly going to stay around for a while. They are
detailed from the hardware level up in the following sections.
3.1 Hardware and Operating System Interface
The operating system tells legacy-NaN and 2008-NaN software apart by
examining the state of the EF_MIPS_NAN2008 flag in the ELF file header of
individual binaries requested for execution with the execve(2) system
call. The value of `0' of the flag denotes legacy-NaN software and the
value of `1' denotes 2008-NaN software.
3.1.1 Floating-Point Emulation
Where possible both legacy-NaN and 2008-NaN software will be supported.
The MIPS architecture itself makes it possible and therefore the FPU
emulator used on hardware that does not implement an FPU will set itself
to the right mode individually for every legacy-NaN or 2008-NaN program
executed.
On Linux the FPU emulator can also be enabled unconditionally even on
hardware that does implement an FPU, with the use of the `nofpu' kernel
option. In this case both legacy-NaN and 2008-NaN software will be
automatically supported, although at a performance loss compared to FPU
hardware.
3.1.2 Global IEEE Std 754 Compliance Mode
A new `ieee754=' kernel option is provided for cases where strict IEEE
Std 754 compliance is not required. This makes it possible to use
binaries from existing Linux distributions on new 2008-NaN hardware making
the transition easier. At least two values are accepted on the right hand
side of this option, `strict' and `relaxed', to select between IEEE Std
754 compliance modes. These modes shall only affect software that does
not make an explicit mode selection as noted in Section 3.1.3 below.
In the `strict' mode, which is the default in the absence of an explicit
`ieee754=' option, only software compatible with the NaN patterns handled
by FPU hardware shall be accepted for execution, that is legacy-NaN
software on legacy-NaN hardware and 2008-NaN software on 2008-NaN
hardware.
In the `relaxed' mode any software shall be accepted for execution,
regardless of whether it is compatible with FPU hardware. Additionally,
in the `relaxed' mode, even if enabled with the FCSR.Enables.V bit, any
IEEE Std 754 Invalid Operation exceptions triggered with an sNaN
instruction operand shall not result in a SIGFPE signal being issued to
the originating process and a qNaN (encoded according to the current mode
set in the floating-point environment) shall be substituted and propagated
through the arithmetic operation requested as with a qNaN operand.
Additionally, to make the dynamic loader aware that the `relaxed' IEEE
Std 754 compliance mode is in effect, bit #25 shall be set in the `a_val'
member of the AT_FLAGS entry of the auxiliary vector created by the
kernel on program execution for any program accepted for this mode. This
bit is in the part of the flag word reserved for system semantic by the
MIPS psABI[1]. This bit shall be set to `0' in the `strict' mode and `1'
in the `relaxed' mode.
Additional values may be accepted with the kernel option and consequently
modes provided now or in the future, but they are beyond the scope of this
document.
3.1.3 Per Program Individual IEEE Std 754 Compliance Mode
Individual programs can select their required IEEE Std 754 compliance
mode regardless of the global mode. Individual selection takes precedence
over the global selection. Programs that select their individual mode
shall have a PT_MIPS_ABIFLAGS segment and shall have bit #1 set in its
`flags1' member. The specific mode selected is then determined by the
value of bit #1 in this segment's `flags2' member, `0' for the `strict'
mode and `1' for the `relaxed' mode.
The semantics of such individually selected IEEE Std 754 compliance
mode is the same as that of the corresponding global mode. See Section
3.1.2 above for further details.
3.1.4 Dynamic IEEE Std 754 Compliance Mode Control
A new request is provided via the prctl(2) system call to let a process
switch its own IEEE Std 754 compliance mode. This is for example to let
a dynamic loader invoked manually set the compliance mode for an
executable requested as if the executable was run directly and its
compliance mode preset by the kernel. The request shall be made as
follows:
int result;
result = prctl(PR_SET_IEEE754_MODE, mode, what);
In this request `mode' shall be set to one of the following:
* PR_IEEE754_MODE_LEGACY -- to set the compliance mode used with programs
which do not make an individual IEEE Std 754 compliance mode selection,
* PR_IEEE754_MODE_STRICT -- to set the `strict' compliance mode,
* PR_IEEE754_MODE_RELAXED -- to set the `relaxed' compliance mode,
and `what' shall be set to either of:
* PR_IEEE754_MODE_NAN_LEGACY -- to select the legacy-NaN encoding mode,
* PR_IEEE754_MODE_NAN_2008 -- to select the 2008-NaN encoding mode.
The kernel shall execute the request according to the rules set out in
Subsection 3.1.2 and Subsection 3.1.3 for the ELF file flag settings
corresponding to the respective IEEE Std 754 compliance and NaN encoding
modes requested.
If the request is successful a non-negative value shall be assigned to
`result', in which bits 7:0 are set to a pattern that would be placed in
bits 31:24, in the same bit order, of the `a_val' member of the AT_FLAGS
entry of the auxiliary vector created by the kernel on program execution
for the mode selected.
3.2 Dynamic Loading
The dynamic loader shall recognise IEEE Std 754 compliance modes and
resolve main executable's dependencies according to rules set below. For
the purpose of these rules a main executable is the binary named in an
execve(2) call to the operating system, and a dependency is any dynamic
shared object additionally loaded, via any means including but not
necessarily limited to a DT_NEEDED dynamic segment entry, an LD_PRELOAD
environment variable or a dlopen(3) library call.
3.2.1 IEEE Std 754 Compliance Mode Selection
Both executables and dynamic shared objects can select their required
IEEE Std 754 compliance mode. A binary requiring a specific compliance
mode shall have a PT_MIPS_ABIFLAGS segment and shall have its contents
set according to rules set out in Section 3.1.3. Such a binary will
be referred to as `strict' or `relaxed'. Binaries that have no
PT_MIPS_ABIFLAGS segment or have one that does not request a specific
compliance mode will be referred to as `legacy'.
3.2.2 Dynamic Dependency Acceptance Rules
The IEEE Std 754 compliance mode requested is determined by the main
executable. Any dynamic shared objects loaded in addition shall respect
the mode according to the rules set below.
For `strict' executables all the dynamic shared objects shall follow the
same legacy-NaN or 2008-NaN ABI, as denoted by the EF_MIPS_NAN2008 flag
described in Section 3.1. The value of the flag shall be the same across
the executable and all the dynamic shared objects loaded together. Both
`strict' and `legacy' dynamic shared objects shall be accepted, however
`relaxed' ones shall be rejected regardless of the value of their
EF_MIPS_NAN2008 flag.
For `relaxed' executables any dynamic shared objects shall be accepted,
`strict', `relaxed' and `legacy' alike, regardless of the value of their
EF_MIPS_NAN2008 flag.
For `legacy' executables the compliance mode is determined by the value
of bit #25 in the `a_val' member of the AT_FLAGS entry of the auxiliary
vector received from the kernel. The value of `0' shall make the dynamic
loader follow the rules for `strict' executables. The value of `1' shall
make the dynamic loader follow the rules for `relaxed' executables.
3.2.3 Dynamic Loading Compatibility Considerations
The encoding for the PT_MIPS_ABIFLAGS segment has been selected such that
old versions of the dynamic loader will reject `relaxed' binaries because
of an unknown `flags2' bit set. This is to prevent execution in an
environment that does not follow the rules set out in this specification
and to signify the need to upgrade. Both `strict' and `legacy' binaries
will run correctly as they follow the rules defined for old versions of
the dynamic loader.
Older versions of the dynamic loader will not process a PT_MIPS_ABIFLAGS
segment and will only examine the EF_MIPS_NAN2008 flag. Very old versions
of the dynamic loader will not even process the flag. It is therefore not
possible to guarantee that the rules set out here will be followed or an
error triggered with older systems.
3.3 Static Linking
The static linker shall recognise IEEE Std 754 compliance modes and
enforce the rules set below for all static links, both final ones that
produce an executable or a dynamic shared object and incremental ones
that produce a relocatable object.
3.3.1 IEEE Std 754 Compliance Mode Selection
All relocatable objects can select their required IEEE Std 754 compliance
mode. An object requiring a specific compliance mode shall have an
SHT_MIPS_ABIFLAGS section called `.MIPS.abiflags' and shall have its
contents set according to rules set out for the PT_MIPS_ABIFLAGS segment
in Section 3.1.3. Such an object will be referred to as `strict' or
`relaxed'. Objects that have no SHT_MIPS_ABIFLAGS section or have one
that does not request a specific compliance mode will be referred to as
`legacy'. On making an executable or a dynamic shared object the linker
shall map an SHT_MIPS_ABIFLAGS section to a PT_MIPS_ABIFLAGS segment.
3.3.2 Static Linking Object Acceptance Rules
The static linker shall follow the user selection as to the linking mode
used, either of `strict' and `relaxed'. The selection will be made
according to the usual way assumed for the environment used, which may be
a command-line option, a property setting, etc.
In the `strict' linking mode both `strict' and `legacy' objects can be
linked together. All shall follow the same legacy-NaN or 2008-NaN ABI, as
denoted by the EF_MIPS_NAN2008 flag described in Section 3.1. The value
of the flag shall be the same across all the objects linked together. The
output of a link involving any `strict' objects shall be marked as
`strict'. No `relaxed' objects shall be allowed in the same link.
In the `relaxed' linking mode any `strict', `relaxed' and `legacy'
objects can be linked together, regardless of the value of their
EF_MIPS_NAN2008 flag. If the flag has the same value across all objects
linked, then the value shall be propagated to the binary produced. The
output shall be marked as `relaxed'. It is recommended that the linker
provides a way to warn the user whenever a `relaxed' link is made of
`strict' and `legacy' objects only.
3.3.3 Static Linking Compliance Mode Warnings
A flag shall be defined in bit #0 of the `flags2' member of the
PT_MIPS_ABIFLAGS section, determining the warning mode for IEEE Std 754
compliance in static linking. This bit shall be set to `0' to enable
the warning mode (`warn' mode) and `1' to disable it (`nowarn' mode). The
bit shall propagate through an incremental static link in an
implementation-defined manner, however it shall be set to `0' in a final
static link.
3.3.4 Static Linking Compatibility Considerations
The encoding for the SHT_MIPS_ABIFLAGS section has been selected such
that old versions of the static linker will reject `relaxed' binaries
because of an unknown `flags2' bit set. This is to prevent incorrectly
annotated objects from being produced that would not guarantee IEEE Std
754 compliance.
The encoding has also been selected such that old versions of the static
linker will merge the `flags1' bit used to tell `legacy' objects and
`strict'/`relaxed' ones apart, automatically marking the output of links
involving any `strict' objects as `strict' as well.
Older versions of the static linker will not process an SHT_MIPS_ABIFLAGS
section and will only examine the EF_MIPS_NAN2008 flag. Consequently they
may allow `relaxed' objects in a single link with `strict' and `legacy'
ones.
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.
3.5 No-float Modules
Certain modules used in dynamic loading or static linking may be marked
as containing no floating-point code, in a way defined by a separate
specification. Such modules shall always be accepted for dynamic loading
and static linking, and for the purpose of IEEE Std 754 compliance checks
treated as if absent.
3.6 Definitions
The following macros shall be defined for the flags introduced by this
document:
/* `flags1' member of the PT_MIPS_ABIFLAGS/SHT_MIPS_ABIFLAGS structure. */
#define MIPS_AFL_FLAGS1_IEEE 2 /* IEEE Std 754 mode defined. */
/* `flags2' members of the PT_MIPS_ABIFLAGS/SHT_MIPS_ABIFLAGS structure. */
#define MIPS_AFL_FLAGS2_NOWARN 1 /* Suppress IEEE Std 754 warnings. */
#define MIPS_AFL_FLAGS2_RELAXED 2 /* Relaxed IEEE Std 754 mode. */
/* `a_val' member of the AT_FLAGS entry. */
#define AV_FLAGS_MIPS_RELAXED (1 << 25) /* Relaxed IEEE Std 754 mode. */
It is unspecified at this time whether the bits referred to with
MIPS_AFL_FLAGS2_RELAXED and AV_FLAGS_MIPS_RELAXED are single-bit bitfields
or the least significant bits of a larger enumeration, to be defined
later.
The following macros shall be defined for the prctl(2) interface
introduced by this document:
/* Control MIPS IEEE 754 compliance modes. */
#define PR_SET_IEEE754_MODE TBA
#define PR_IEEE754_MODE_LEGACY 0 /* Legacy mode. */
#define PR_IEEE754_MODE_STRICT 1 /* Strict mode. */
#define PR_IEEE754_MODE_RELAXED 2 /* Relaxed mode. */
#define PR_IEEE754_MODE_NAN_LEGACY 0 /* Set legacy NaN encoding. */
#define PR_IEEE754_MODE_NAN_2008 1 /* Set 2008 NaN encoding. */
4. Implementation Notes
For the GNU linker the command-line options to select between the
`strict' and the `relaxed' IEEE Std 754 compliance modes will be
`--ieee=strict' and `--ieee=relaxed', respectively. The latter will issue
a compliance warning in the case where all input objects were either
`strict' and `warn' or `legacy' mode, unless a `--ieee=nowarn' option has
also been used. There will be a `--ieee=warn' option as well to revert
the effect of the former option.
For the GNU assembler the directives to select between the `strict' and
the `relaxed' IEEE Std 754 compliance modes will be `.ieee strict' and
`.ieee relaxed', respectively. Equivalent command-line options will be
present, `-mieee=strict' and `-mieee=relaxed', respectively. There will
be `.ieee nowarn' and `.ieee warn' directives as well to set and clear
the IEEE Std 754 warning flag respectively in the SHT_MIPS_ABIFLAGS
section. Their corresponding command-line options will be `-mieee=nowarn'
and `-mieee=warn' respectively.
For the GNU Compiler Collection (GCC) the following command-line will be
accepted:
* `-mieee=strict', making the toolchain produce `strict' binaries,
* `-mieee=relaxed-exec', making the toolchain produce `strict' shared
libraries and `relaxed' executables,
* `-mieee=relaxed', making the toolchain produce `relaxed' binaries,
* `-mieee=force-relaxed', making the toolchain produce `relaxed' binaries,
while suppressing IEEE Std 754 static linking warnings.
It is expected that the two former options will be available as
configuration defaults to be selected at the GCC build time.
Any or all of these options may have effects beyond propagating the IEEE
Std 754 compliance mode down to the assembler and the linker. In
particular `-mieee=strict' is expected to guarantee code generated to
fully comply to IEEE Std 754 rather than only as far as NaN representation
is concerned.
There may be further GCC options to control IEEE Std 754 compliance, to
be defined.
5. Future Considerations
While at the time of this writing the `strict' and `relaxed' IEEE Std 754
compliance modes only apply to NaN representation patterns, it is possible
that in the future other IEEE Std 754 compliance matters may require
communicating through linking and loading down to the operating system
kernel. Therefore a decision has been made to use generic names for the
modes, macros, directives and option names defined here. If such a need
arises in the future, then the meaning of these names may be extended to
cover other compliance aspects and further modes can be added that are
intermediate between `strict' and `relaxed', to be used with the `.ieee'
directive and the `-mieee=' command-line options.
References:
[1] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
Supplement, 3rd Edition", Section "Process Stack", pp. 3-33, 3-34
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
2015-11-14 10:42 ` Maciej W. Rozycki
(?)
@ 2015-11-14 16:06 ` Cary Coutant
2015-11-16 8:56 ` Maciej W. Rozycki
-1 siblings, 1 reply; 17+ messages in thread
From: Cary Coutant @ 2015-11-14 16:06 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, Binutils, GCC Development,
Matthew Fortune, Daniel Sanders, Leonid Yegoshin
> 3.3.2 Static Linking Object Acceptance Rules
>
> The static linker shall follow the user selection as to the linking mode
> used, either of `strict' and `relaxed'. The selection will be made
> according to the usual way assumed for the environment used, which may be
> a command-line option, a property setting, etc.
>
> In the `strict' linking mode both `strict' and `legacy' objects can be
> linked together. All shall follow the same legacy-NaN or 2008-NaN ABI, as
> denoted by the EF_MIPS_NAN2008 flag described in Section 3.1. The value
> of the flag shall be the same across all the objects linked together. The
> output of a link involving any `strict' objects shall be marked as
> `strict'. No `relaxed' objects shall be allowed in the same link.
>
> In the `relaxed' linking mode any `strict', `relaxed' and `legacy'
> objects can be linked together, regardless of the value of their
> EF_MIPS_NAN2008 flag. If the flag has the same value across all objects
> linked, then the value shall be propagated to the binary produced. The
> output shall be marked as `relaxed'. It is recommended that the linker
> provides a way to warn the user whenever a `relaxed' link is made of
> `strict' and `legacy' objects only.
This paragraph first says that "If the flag has the same value across
all objects linked, then the value shall be propagated to the binary
produced", but then says the "output shall be marked as `relaxed'."
Are you missing an "Otherwise" there?
Early on in the document, you mention "this applies regardless of
whether it relies on the use of NaN data or IEEE Std 754 arithmetic in
the first place," yet your solution is only two-state. Wouldn't it be
better to have a three-state solution where objects that do not in
fact rely on the NaN representation at all can be marked as "don't
care"? Such objects could always be mixed with either strict or
relaxed objects, regardless of linking mode.
-cary
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-16 8:56 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-16 8:56 UTC (permalink / raw
To: Cary Coutant
Cc: linux-mips, libc-alpha, Binutils, GCC Development,
Matthew Fortune, Daniel Sanders, Leonid Yegoshin
On Sat, 14 Nov 2015, Cary Coutant wrote:
> > 3.3.2 Static Linking Object Acceptance Rules
> >
> > The static linker shall follow the user selection as to the linking mode
> > used, either of `strict' and `relaxed'. The selection will be made
> > according to the usual way assumed for the environment used, which may be
> > a command-line option, a property setting, etc.
> >
> > In the `strict' linking mode both `strict' and `legacy' objects can be
> > linked together. All shall follow the same legacy-NaN or 2008-NaN ABI, as
> > denoted by the EF_MIPS_NAN2008 flag described in Section 3.1. The value
> > of the flag shall be the same across all the objects linked together. The
> > output of a link involving any `strict' objects shall be marked as
> > `strict'. No `relaxed' objects shall be allowed in the same link.
> >
> > In the `relaxed' linking mode any `strict', `relaxed' and `legacy'
> > objects can be linked together, regardless of the value of their
> > EF_MIPS_NAN2008 flag. If the flag has the same value across all objects
> > linked, then the value shall be propagated to the binary produced. The
> > output shall be marked as `relaxed'. It is recommended that the linker
> > provides a way to warn the user whenever a `relaxed' link is made of
> > `strict' and `legacy' objects only.
>
> This paragraph first says that "If the flag has the same value across
> all objects linked, then the value shall be propagated to the binary
> produced", but then says the "output shall be marked as `relaxed'."
> Are you missing an "Otherwise" there?
The EF_MIPS_NAN2008 flag (if the same across all the objects linked in
the `relaxed' mode) shall be propagated to the binary produced and the
output marked as `relaxed'. If you think this is not clear from the
wording used, then I can think of rewording the paragraph. Please note
however that nowhere across this document the term `flag' is used to refer
to `relaxed' vs `strict' vs `legacy' annotation, so I'm not really sure
why this should be ambiguous.
> Early on in the document, you mention "this applies regardless of
> whether it relies on the use of NaN data or IEEE Std 754 arithmetic in
> the first place," yet your solution is only two-state. Wouldn't it be
> better to have a three-state solution where objects that do not in
> fact rely on the NaN representation at all can be marked as "don't
> care"? Such objects could always be mixed with either strict or
> relaxed objects, regardless of linking mode.
I find it interesting that you raise this point as this was actually
considered and deferred to investigation at a later stage.
The reason is we actually have a no-FP annotation already -- in the GNU
attribute section (propagated these days to the `fp_abi' member of MIPS
ABI flags by BFD) -- however the encoding is so unfortunate as to make it
impossible in ELF binary objects to tell apart ones explicitly annotated
as containing no FP code (typically in compiler-generated code, such as
made by GCC invoked with the `-mno-float' command-line option) and ones
with no annotation at all (either legacy compiler-generated code or often
handcoded assembly sources). This is because the no-FP annotation is also
the default value (0) of the attribute in question and is therefore
removed in processing by BFD rather than being recorded in ELF output.
It is of course possible to tell corresponding sources apart, however it
requires a rewrite of parts of attribute handling in BFD so that the
original annotation is actually unambiguously propagated to an ELF object
produced by the assembler. Such a change being considerable enough on its
own was decided to be made separately, as it can be added later on at any
time, as an extra case in addition to the two already handled here which
are required anyway. This follows the principle of making one step at a
time.
There is also a question of a no-FP executable pulling in an FP DSO,
either at the load time or with dlopen(3): how is such a process supposed
to be configured -- as `strict' or `relaxed'? No clear answer has been
found to this question yet.
Does this explanation address your concern?
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-16 8:56 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-16 8:56 UTC (permalink / raw
To: Cary Coutant
Cc: linux-mips, libc-alpha, Binutils, GCC Development,
Matthew Fortune, Daniel Sanders, Leonid Yegoshin
On Sat, 14 Nov 2015, Cary Coutant wrote:
> > 3.3.2 Static Linking Object Acceptance Rules
> >
> > The static linker shall follow the user selection as to the linking mode
> > used, either of `strict' and `relaxed'. The selection will be made
> > according to the usual way assumed for the environment used, which may be
> > a command-line option, a property setting, etc.
> >
> > In the `strict' linking mode both `strict' and `legacy' objects can be
> > linked together. All shall follow the same legacy-NaN or 2008-NaN ABI, as
> > denoted by the EF_MIPS_NAN2008 flag described in Section 3.1. The value
> > of the flag shall be the same across all the objects linked together. The
> > output of a link involving any `strict' objects shall be marked as
> > `strict'. No `relaxed' objects shall be allowed in the same link.
> >
> > In the `relaxed' linking mode any `strict', `relaxed' and `legacy'
> > objects can be linked together, regardless of the value of their
> > EF_MIPS_NAN2008 flag. If the flag has the same value across all objects
> > linked, then the value shall be propagated to the binary produced. The
> > output shall be marked as `relaxed'. It is recommended that the linker
> > provides a way to warn the user whenever a `relaxed' link is made of
> > `strict' and `legacy' objects only.
>
> This paragraph first says that "If the flag has the same value across
> all objects linked, then the value shall be propagated to the binary
> produced", but then says the "output shall be marked as `relaxed'."
> Are you missing an "Otherwise" there?
The EF_MIPS_NAN2008 flag (if the same across all the objects linked in
the `relaxed' mode) shall be propagated to the binary produced and the
output marked as `relaxed'. If you think this is not clear from the
wording used, then I can think of rewording the paragraph. Please note
however that nowhere across this document the term `flag' is used to refer
to `relaxed' vs `strict' vs `legacy' annotation, so I'm not really sure
why this should be ambiguous.
> Early on in the document, you mention "this applies regardless of
> whether it relies on the use of NaN data or IEEE Std 754 arithmetic in
> the first place," yet your solution is only two-state. Wouldn't it be
> better to have a three-state solution where objects that do not in
> fact rely on the NaN representation at all can be marked as "don't
> care"? Such objects could always be mixed with either strict or
> relaxed objects, regardless of linking mode.
I find it interesting that you raise this point as this was actually
considered and deferred to investigation at a later stage.
The reason is we actually have a no-FP annotation already -- in the GNU
attribute section (propagated these days to the `fp_abi' member of MIPS
ABI flags by BFD) -- however the encoding is so unfortunate as to make it
impossible in ELF binary objects to tell apart ones explicitly annotated
as containing no FP code (typically in compiler-generated code, such as
made by GCC invoked with the `-mno-float' command-line option) and ones
with no annotation at all (either legacy compiler-generated code or often
handcoded assembly sources). This is because the no-FP annotation is also
the default value (0) of the attribute in question and is therefore
removed in processing by BFD rather than being recorded in ELF output.
It is of course possible to tell corresponding sources apart, however it
requires a rewrite of parts of attribute handling in BFD so that the
original annotation is actually unambiguously propagated to an ELF object
produced by the assembler. Such a change being considerable enough on its
own was decided to be made separately, as it can be added later on at any
time, as an extra case in addition to the two already handled here which
are required anyway. This follows the principle of making one step at a
time.
There is also a question of a no-FP executable pulling in an FP DSO,
either at the load time or with dlopen(3): how is such a process supposed
to be configured -- as `strict' or `relaxed'? No clear answer has been
found to this question yet.
Does this explanation address your concern?
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-17 15:07 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2015-11-17 15:07 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Sat, 14 Nov 2015, Maciej W. Rozycki wrote:
> Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to guarantee code generated to
> fully comply to IEEE Std 754 rather than only as far as NaN representation
> is concerned.
"guarantee" seems rather strong given the various known issues with (lack
of) Annex F support in GCC. Do you have any actual configuration in mind
it would affect, MIPS-specific or otherwise? For
non-architecture-specific things, -std= options for C standards
conformance are meant to enable whatever options are required (e.g. they
disable the default -ffp-contract=fast), without affecting things not
required by the standards by default (so they don't enable -frounding-math
or -fsignaling-nans, for example).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-17 15:07 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2015-11-17 15:07 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Sat, 14 Nov 2015, Maciej W. Rozycki wrote:
> Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to guarantee code generated to
> fully comply to IEEE Std 754 rather than only as far as NaN representation
> is concerned.
"guarantee" seems rather strong given the various known issues with (lack
of) Annex F support in GCC. Do you have any actual configuration in mind
it would affect, MIPS-specific or otherwise? For
non-architecture-specific things, -std= options for C standards
conformance are meant to enable whatever options are required (e.g. they
disable the default -ffp-contract=fast), without affecting things not
required by the standards by default (so they don't enable -frounding-math
or -fsignaling-nans, for example).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-20 17:16 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-20 17:16 UTC (permalink / raw
To: Joseph Myers
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Tue, 17 Nov 2015, Joseph Myers wrote:
> > Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to guarantee code generated to
> > fully comply to IEEE Std 754 rather than only as far as NaN representation
> > is concerned.
>
> "guarantee" seems rather strong given the various known issues with (lack
> of) Annex F support in GCC.
Well, but aren't these current implementation shortcomings (i.e. bugs)
rather than a design principle? I can weaken the language here, but if
the former is the case, then I think we don't need to factor in the
existence of bugs into an interface specification.
> Do you have any actual configuration in mind it would affect,
> MIPS-specific or otherwise? For non-architecture-specific things, -std=
> options for C standards conformance are meant to enable whatever options
> are required (e.g. they disable the default -ffp-contract=fast), without
> affecting things not required by the standards by default (so they don't
> enable -frounding-math or -fsignaling-nans, for example).
The target audience for the `-mieee=strict' option is in my idea a
non-technical user, say a physicist, who does not necessarily know or is
fluent with the guts of computer hardware and who has the need to build
and reliably run their software which uses IEEE Std 754 arithmetic.
Rather than giving such a user necessarily lengthy explanations as to the
complexity of the situation I'd prefer to give them this single option to
guarantee (modulo bugs, as noted above) that a piece of software built
with this option will either produce correct (as in "standard-compliant")
results or refuse to run.
There is also a corresponding `--with-ieee=strict' configure-time option
for users who want to build their own compiler system which guarantees
such compliance by default.
I think the `-std=' options are a little bit too broad in that they
control more than just the IEEE Std 754 aspect of standards compliance.
Of course the setting of `-mieee=' may in fact be a one-way dependency of
`-std=', up to a further override. I haven't implemented such a
dependency in my prototype, however I think it might be a good idea to
have it.
What I have implemented is a dependency between `-mieee=' and the
internal option to control the compliance mode for NaN encodings. That
has encountered an unexpected complication though which I was not able to
resolve without turning the option handling machinery upside down, and I
found that code really hard to follow. So I decided to defer it as not
the main scope of the matter and proceed with the rest of the feature.
Once the option handling has been sorted out, a similar dependency can be
introduced between `-std=' and `-mieee='.
I'll post the details of the option handling issue with the GCC patches.
Does this answer address your concerns?
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-20 17:16 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-20 17:16 UTC (permalink / raw
To: Joseph Myers
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Tue, 17 Nov 2015, Joseph Myers wrote:
> > Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to guarantee code generated to
> > fully comply to IEEE Std 754 rather than only as far as NaN representation
> > is concerned.
>
> "guarantee" seems rather strong given the various known issues with (lack
> of) Annex F support in GCC.
Well, but aren't these current implementation shortcomings (i.e. bugs)
rather than a design principle? I can weaken the language here, but if
the former is the case, then I think we don't need to factor in the
existence of bugs into an interface specification.
> Do you have any actual configuration in mind it would affect,
> MIPS-specific or otherwise? For non-architecture-specific things, -std=
> options for C standards conformance are meant to enable whatever options
> are required (e.g. they disable the default -ffp-contract=fast), without
> affecting things not required by the standards by default (so they don't
> enable -frounding-math or -fsignaling-nans, for example).
The target audience for the `-mieee=strict' option is in my idea a
non-technical user, say a physicist, who does not necessarily know or is
fluent with the guts of computer hardware and who has the need to build
and reliably run their software which uses IEEE Std 754 arithmetic.
Rather than giving such a user necessarily lengthy explanations as to the
complexity of the situation I'd prefer to give them this single option to
guarantee (modulo bugs, as noted above) that a piece of software built
with this option will either produce correct (as in "standard-compliant")
results or refuse to run.
There is also a corresponding `--with-ieee=strict' configure-time option
for users who want to build their own compiler system which guarantees
such compliance by default.
I think the `-std=' options are a little bit too broad in that they
control more than just the IEEE Std 754 aspect of standards compliance.
Of course the setting of `-mieee=' may in fact be a one-way dependency of
`-std=', up to a further override. I haven't implemented such a
dependency in my prototype, however I think it might be a good idea to
have it.
What I have implemented is a dependency between `-mieee=' and the
internal option to control the compliance mode for NaN encodings. That
has encountered an unexpected complication though which I was not able to
resolve without turning the option handling machinery upside down, and I
found that code really hard to follow. So I decided to defer it as not
the main scope of the matter and proceed with the rest of the feature.
Once the option handling has been sorted out, a similar dependency can be
introduced between `-std=' and `-mieee='.
I'll post the details of the option handling issue with the GCC patches.
Does this answer address your concerns?
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-20 18:25 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2015-11-20 18:25 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 20 Nov 2015, Maciej W. Rozycki wrote:
> The target audience for the `-mieee=strict' option is in my idea a
> non-technical user, say a physicist, who does not necessarily know or is
> fluent with the guts of computer hardware and who has the need to build
> and reliably run their software which uses IEEE Std 754 arithmetic.
> Rather than giving such a user necessarily lengthy explanations as to the
> complexity of the situation I'd prefer to give them this single option to
> guarantee (modulo bugs, as noted above) that a piece of software built
> with this option will either produce correct (as in "standard-compliant")
> results or refuse to run.
This does not make any sense. The correspondence between IEEE 754
operations and source code in C or other languages is extremely
complicated. If the user thinks of C as some form of portable assembler
for IEEE 754 operations, that is not something effectively supportable.
Can we assume that if the user depends on rounding modes, they will use
the FENV_ACCESS pragma (not implemented, of course) or -frounding-math?
Can we assume that their dependence on the absence of contraction of
expressions is in accordance with ISO C rules (again, FP_CONTRACT isn't
implemented but -ffp-contract=off is)? Can we assume that they don't
depend on signaling NaNs? Can we assume they don't depend on trap
handlers that count the number of times a given exception occurs, since
that is explicitly unsupported by ISO C?
An option like that has to be defined in terms of existing C bindings for
IEEE 754, not in terms of supporting users who don't know what they are
doing and are unfamiliar with how C source code constructs are mapped to
IEEE 754 operations and what features the C standard allows non-default
pragmas or options to be required for.
> Does this answer address your concerns?
No, the option concept as described seems too irremediably vague.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-20 18:25 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2015-11-20 18:25 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 20 Nov 2015, Maciej W. Rozycki wrote:
> The target audience for the `-mieee=strict' option is in my idea a
> non-technical user, say a physicist, who does not necessarily know or is
> fluent with the guts of computer hardware and who has the need to build
> and reliably run their software which uses IEEE Std 754 arithmetic.
> Rather than giving such a user necessarily lengthy explanations as to the
> complexity of the situation I'd prefer to give them this single option to
> guarantee (modulo bugs, as noted above) that a piece of software built
> with this option will either produce correct (as in "standard-compliant")
> results or refuse to run.
This does not make any sense. The correspondence between IEEE 754
operations and source code in C or other languages is extremely
complicated. If the user thinks of C as some form of portable assembler
for IEEE 754 operations, that is not something effectively supportable.
Can we assume that if the user depends on rounding modes, they will use
the FENV_ACCESS pragma (not implemented, of course) or -frounding-math?
Can we assume that their dependence on the absence of contraction of
expressions is in accordance with ISO C rules (again, FP_CONTRACT isn't
implemented but -ffp-contract=off is)? Can we assume that they don't
depend on signaling NaNs? Can we assume they don't depend on trap
handlers that count the number of times a given exception occurs, since
that is explicitly unsupported by ISO C?
An option like that has to be defined in terms of existing C bindings for
IEEE 754, not in terms of supporting users who don't know what they are
doing and are unfamiliar with how C source code constructs are mapped to
IEEE 754 operations and what features the C standard allows non-default
pragmas or options to be required for.
> Does this answer address your concerns?
No, the option concept as described seems too irremediably vague.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-27 15:47 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-27 15:47 UTC (permalink / raw
To: Joseph Myers
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 20 Nov 2015, Joseph Myers wrote:
> > The target audience for the `-mieee=strict' option is in my idea a
> > non-technical user, say a physicist, who does not necessarily know or is
> > fluent with the guts of computer hardware and who has the need to build
> > and reliably run their software which uses IEEE Std 754 arithmetic.
> > Rather than giving such a user necessarily lengthy explanations as to the
> > complexity of the situation I'd prefer to give them this single option to
> > guarantee (modulo bugs, as noted above) that a piece of software built
> > with this option will either produce correct (as in "standard-compliant")
> > results or refuse to run.
>
> This does not make any sense. The correspondence between IEEE 754
> operations and source code in C or other languages is extremely
> complicated. If the user thinks of C as some form of portable assembler
> for IEEE 754 operations, that is not something effectively supportable.
>
> Can we assume that if the user depends on rounding modes, they will use
> the FENV_ACCESS pragma (not implemented, of course) or -frounding-math?
> Can we assume that their dependence on the absence of contraction of
> expressions is in accordance with ISO C rules (again, FP_CONTRACT isn't
> implemented but -ffp-contract=off is)? Can we assume that they don't
> depend on signaling NaNs? Can we assume they don't depend on trap
> handlers that count the number of times a given exception occurs, since
> that is explicitly unsupported by ISO C?
>
> An option like that has to be defined in terms of existing C bindings for
> IEEE 754, not in terms of supporting users who don't know what they are
> doing and are unfamiliar with how C source code constructs are mapped to
> IEEE 754 operations and what features the C standard allows non-default
> pragmas or options to be required for.
These are all valid points, thank you for raising them.
One problem with the situation you have summarised is it may be possible
(though perhaps challenging) for software writers to understand it. They
may take it into account while implementing their code, and they may even
provide information to the person compiling their piece of software as to
which revision of the relevant language standard to compile for, maybe
even some guidelines to which options to select with particular compilers.
I find it highly unlikely though that the writers will (be able to) chase
individual targets and any obscure hardware-dependent options the targets
may provide. And we cannot expect people compiling software to be
educated enough to understand all the complexities behind all the
standards and particular implementations involved.
What I think we therefore need is an option that, on top of the generic
compiler options like ones you've noted, will control to permit or forbid
target-specific (in this case MIPS-specific) deviations from IEEE Std 754,
its language bindings and the ABI that has been out there for at least 20
years (concerning the Linux target in particular). And I don't think
having to explain the peculiarities of NaN encodings and their dependency
on hardware implementation in this case to people compiling software is a
good idea. I think they won't just get it as I've even seen people very
familiar with computer architectures getting lost.
As you may see in the GCC patches I have just posted the `-mieee=strict'
option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
the only target-specific option so far. So this does exactly what I
outlined above.
NB I am not going to dive into implementation shortcomings GCC has now as
I don't think they really matter for this consideration. There's no way
an option is going to make a compiler do what it does not implement, and
users will have to live with that. I think the presence or absence of an
option to control target-specific aspects of IEEE Std 754 compliance is
really tangential to any compiler shortcomings, and any such shortcomings
addressed in the future will apply accordingly to the mode of compilation
set with `-mieee=strict'.
Taking the observations above into account I propose to reword the
paragraph you questioned as follows:
"Any or all of these options may have effects beyond propagating the IEEE
Std 754 compliance mode down to the assembler and the linker. In
particular `-mieee=strict' is expected to produce strictly compliant code,
which in the context of this specification is defined as: following IEEE
Std 754 as closely as the programming language binding to the standard
(defined in the relevant language standard), the compiler implementation
and target hardware permit. This means the use of this option may affect
code produced in ways beyond NaN representation only."
> > Does this answer address your concerns?
>
> No, the option concept as described seems too irremediably vague.
Does this explanation give you a better idea of what I have in mind? Do
you still have concerns about the feasibility of the idea?
Thank you for your input.
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-27 15:47 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2015-11-27 15:47 UTC (permalink / raw
To: Joseph Myers
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 20 Nov 2015, Joseph Myers wrote:
> > The target audience for the `-mieee=strict' option is in my idea a
> > non-technical user, say a physicist, who does not necessarily know or is
> > fluent with the guts of computer hardware and who has the need to build
> > and reliably run their software which uses IEEE Std 754 arithmetic.
> > Rather than giving such a user necessarily lengthy explanations as to the
> > complexity of the situation I'd prefer to give them this single option to
> > guarantee (modulo bugs, as noted above) that a piece of software built
> > with this option will either produce correct (as in "standard-compliant")
> > results or refuse to run.
>
> This does not make any sense. The correspondence between IEEE 754
> operations and source code in C or other languages is extremely
> complicated. If the user thinks of C as some form of portable assembler
> for IEEE 754 operations, that is not something effectively supportable.
>
> Can we assume that if the user depends on rounding modes, they will use
> the FENV_ACCESS pragma (not implemented, of course) or -frounding-math?
> Can we assume that their dependence on the absence of contraction of
> expressions is in accordance with ISO C rules (again, FP_CONTRACT isn't
> implemented but -ffp-contract=off is)? Can we assume that they don't
> depend on signaling NaNs? Can we assume they don't depend on trap
> handlers that count the number of times a given exception occurs, since
> that is explicitly unsupported by ISO C?
>
> An option like that has to be defined in terms of existing C bindings for
> IEEE 754, not in terms of supporting users who don't know what they are
> doing and are unfamiliar with how C source code constructs are mapped to
> IEEE 754 operations and what features the C standard allows non-default
> pragmas or options to be required for.
These are all valid points, thank you for raising them.
One problem with the situation you have summarised is it may be possible
(though perhaps challenging) for software writers to understand it. They
may take it into account while implementing their code, and they may even
provide information to the person compiling their piece of software as to
which revision of the relevant language standard to compile for, maybe
even some guidelines to which options to select with particular compilers.
I find it highly unlikely though that the writers will (be able to) chase
individual targets and any obscure hardware-dependent options the targets
may provide. And we cannot expect people compiling software to be
educated enough to understand all the complexities behind all the
standards and particular implementations involved.
What I think we therefore need is an option that, on top of the generic
compiler options like ones you've noted, will control to permit or forbid
target-specific (in this case MIPS-specific) deviations from IEEE Std 754,
its language bindings and the ABI that has been out there for at least 20
years (concerning the Linux target in particular). And I don't think
having to explain the peculiarities of NaN encodings and their dependency
on hardware implementation in this case to people compiling software is a
good idea. I think they won't just get it as I've even seen people very
familiar with computer architectures getting lost.
As you may see in the GCC patches I have just posted the `-mieee=strict'
option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
the only target-specific option so far. So this does exactly what I
outlined above.
NB I am not going to dive into implementation shortcomings GCC has now as
I don't think they really matter for this consideration. There's no way
an option is going to make a compiler do what it does not implement, and
users will have to live with that. I think the presence or absence of an
option to control target-specific aspects of IEEE Std 754 compliance is
really tangential to any compiler shortcomings, and any such shortcomings
addressed in the future will apply accordingly to the mode of compilation
set with `-mieee=strict'.
Taking the observations above into account I propose to reword the
paragraph you questioned as follows:
"Any or all of these options may have effects beyond propagating the IEEE
Std 754 compliance mode down to the assembler and the linker. In
particular `-mieee=strict' is expected to produce strictly compliant code,
which in the context of this specification is defined as: following IEEE
Std 754 as closely as the programming language binding to the standard
(defined in the relevant language standard), the compiler implementation
and target hardware permit. This means the use of this option may affect
code produced in ways beyond NaN representation only."
> > Does this answer address your concerns?
>
> No, the option concept as described seems too irremediably vague.
Does this explanation give you a better idea of what I have in mind? Do
you still have concerns about the feasibility of the idea?
Thank you for your input.
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-27 18:03 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2015-11-27 18:03 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 27 Nov 2015, Maciej W. Rozycki wrote:
> I find it highly unlikely though that the writers will (be able to) chase
> individual targets and any obscure hardware-dependent options the targets
> may provide. And we cannot expect people compiling software to be
What that says to me is that there should be an architecture-independent
option (-fieee?) that, for architectures where the default configuration
may have architecture-specific deviations from the normal defaults
regarding conformance to IEEE 754 language bindings but there are options
to disable those deviations, disables those deviations. For example, on
alpha that would imply -mieee-with-inexact. On architectures without such
issues (beyond bugs that should be fixed unconditionally, not conditional
on a command-line option, or issues with the hardware ISA that are
infeasible to fix in software), that option would do nothing (beyond any
architecture-independent effects it might have such as implying
-fno-fast-math).
> As you may see in the GCC patches I have just posted the `-mieee=strict'
> option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
> the only target-specific option so far. So this does exactly what I
> outlined above.
I am doubtful about the architecture-specific option setting
architecture-independent options here. Having it the other way round as I
suggested above would make more sense to me.
> "Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to produce strictly compliant code,
> which in the context of this specification is defined as: following IEEE
> Std 754 as closely as the programming language binding to the standard
> (defined in the relevant language standard), the compiler implementation
> and target hardware permit. This means the use of this option may affect
> code produced in ways beyond NaN representation only."
>
> > > Does this answer address your concerns?
> >
> > No, the option concept as described seems too irremediably vague.
>
> Does this explanation give you a better idea of what I have in mind? Do
> you still have concerns about the feasibility of the idea?
It's better defined, but I think it would be better for -fieee to imply
-mieee=strict -fno-fast-math (or whatever) rather than for -mieee=strict
to imply architecture-independent options. Cf. i386 and sh where
-ffinite-math-only affects architecture-specific options.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2015-11-27 18:03 ` Joseph Myers
0 siblings, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2015-11-27 18:03 UTC (permalink / raw
To: Maciej W. Rozycki
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 27 Nov 2015, Maciej W. Rozycki wrote:
> I find it highly unlikely though that the writers will (be able to) chase
> individual targets and any obscure hardware-dependent options the targets
> may provide. And we cannot expect people compiling software to be
What that says to me is that there should be an architecture-independent
option (-fieee?) that, for architectures where the default configuration
may have architecture-specific deviations from the normal defaults
regarding conformance to IEEE 754 language bindings but there are options
to disable those deviations, disables those deviations. For example, on
alpha that would imply -mieee-with-inexact. On architectures without such
issues (beyond bugs that should be fixed unconditionally, not conditional
on a command-line option, or issues with the hardware ISA that are
infeasible to fix in software), that option would do nothing (beyond any
architecture-independent effects it might have such as implying
-fno-fast-math).
> As you may see in the GCC patches I have just posted the `-mieee=strict'
> option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
> the only target-specific option so far. So this does exactly what I
> outlined above.
I am doubtful about the architecture-specific option setting
architecture-independent options here. Having it the other way round as I
suggested above would make more sense to me.
> "Any or all of these options may have effects beyond propagating the IEEE
> Std 754 compliance mode down to the assembler and the linker. In
> particular `-mieee=strict' is expected to produce strictly compliant code,
> which in the context of this specification is defined as: following IEEE
> Std 754 as closely as the programming language binding to the standard
> (defined in the relevant language standard), the compiler implementation
> and target hardware permit. This means the use of this option may affect
> code produced in ways beyond NaN representation only."
>
> > > Does this answer address your concerns?
> >
> > No, the option concept as described seems too irremediably vague.
>
> Does this explanation give you a better idea of what I have in mind? Do
> you still have concerns about the feasibility of the idea?
It's better defined, but I think it would be better for -fieee to imply
-mieee=strict -fno-fast-math (or whatever) rather than for -mieee=strict
to imply architecture-independent options. Cf. i386 and sh where
-ffinite-math-only affects architecture-specific options.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2016-01-07 0:55 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2016-01-07 0:55 UTC (permalink / raw
To: Joseph Myers
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 27 Nov 2015, Joseph Myers wrote:
> > I find it highly unlikely though that the writers will (be able to) chase
> > individual targets and any obscure hardware-dependent options the targets
> > may provide. And we cannot expect people compiling software to be
>
> What that says to me is that there should be an architecture-independent
> option (-fieee?) that, for architectures where the default configuration
> may have architecture-specific deviations from the normal defaults
> regarding conformance to IEEE 754 language bindings but there are options
> to disable those deviations, disables those deviations. For example, on
> alpha that would imply -mieee-with-inexact. On architectures without such
> issues (beyond bugs that should be fixed unconditionally, not conditional
> on a command-line option, or issues with the hardware ISA that are
> infeasible to fix in software), that option would do nothing (beyond any
> architecture-independent effects it might have such as implying
> -fno-fast-math).
I'm fine with `-fieee'/`-fno-ieee', and corresponding
`--with-ieee=yes/no' configuration options.
I have been aware of the Alpha processor's imprecise IEEE 754 exception
mode and while working on the specification concerned here I had in my
mind the possibility of expanding the semantics of the MIPS target's
`-mieee=' option to cover the somewhat similar imprecise IEEE 754
exception mode of the MIPS R8000 processor, or any optimisations of the
same or a different kind the MIPS architecture might introduce in the
future.
Since (regrettably) by now the Alpha architecture has become a legacy one
I didn't consider it important enough to create a generic option which
would only control the Alpha target, in addition to the MIPS target being
considered here. So I am actually glad you proposed it as I agree it will
make things cleaner.
> > As you may see in the GCC patches I have just posted the `-mieee=strict'
> > option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
> > the only target-specific option so far. So this does exactly what I
> > outlined above.
>
> I am doubtful about the architecture-specific option setting
> architecture-independent options here. Having it the other way round as I
> suggested above would make more sense to me.
Agreed, as noted above.
> > "Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to produce strictly compliant code,
> > which in the context of this specification is defined as: following IEEE
> > Std 754 as closely as the programming language binding to the standard
> > (defined in the relevant language standard), the compiler implementation
> > and target hardware permit. This means the use of this option may affect
> > code produced in ways beyond NaN representation only."
> >
> > > > Does this answer address your concerns?
> > >
> > > No, the option concept as described seems too irremediably vague.
> >
> > Does this explanation give you a better idea of what I have in mind? Do
> > you still have concerns about the feasibility of the idea?
>
> It's better defined, but I think it would be better for -fieee to imply
> -mieee=strict -fno-fast-math (or whatever) rather than for -mieee=strict
> to imply architecture-independent options. Cf. i386 and sh where
> -ffinite-math-only affects architecture-specific options.
Thanks for the references. I'll have a look in the course of updating
the implementation.
With `-fieee' in the picture I think we can get rid of GCC's
target-specific high-level `-mieee=' option, as having become redundant,
and retain the low-level `-mrelaxed-nan=' only, with the assumption that
only power users will need to control this setting directly and they will
necessarily have studied and understood all the implications. Additional
low-level options can be added in the future as needed to control the
R8000 exception mode or other architectural features affecting IEEE 754
arithmetic, wired to `-fieee' as appropriate.
I'm going to retain the assembler and linker options and directives of
the `*ieee*' form though as their purpose is a bit different -- to set
flags in a binary file rather than affecting code generation -- and I
don't think it makes sense to expand the namespace there. The effects of
these options are cumulative rather than mutually exclusive and it's the
names of individual bits or enumeration fields within binary file's
control structures, referred in the option's or directive's argument, that
tell features apart.
I'll be updating the specification and the proposed implementation
shortly, and I also think the addition of `-fieee' will then better be
done as a separate preparatory change, initially affecting the Alpha
target only. Please let me know if I missed anything, or if you have any
other questions or comments.
Thank you for your input, and Happy New Year!
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
@ 2016-01-07 0:55 ` Maciej W. Rozycki
0 siblings, 0 replies; 17+ messages in thread
From: Maciej W. Rozycki @ 2016-01-07 0:55 UTC (permalink / raw
To: Joseph Myers
Cc: linux-mips, libc-alpha, binutils, gcc, Matthew Fortune,
Daniel Sanders, Leonid Yegoshin
On Fri, 27 Nov 2015, Joseph Myers wrote:
> > I find it highly unlikely though that the writers will (be able to) chase
> > individual targets and any obscure hardware-dependent options the targets
> > may provide. And we cannot expect people compiling software to be
>
> What that says to me is that there should be an architecture-independent
> option (-fieee?) that, for architectures where the default configuration
> may have architecture-specific deviations from the normal defaults
> regarding conformance to IEEE 754 language bindings but there are options
> to disable those deviations, disables those deviations. For example, on
> alpha that would imply -mieee-with-inexact. On architectures without such
> issues (beyond bugs that should be fixed unconditionally, not conditional
> on a command-line option, or issues with the hardware ISA that are
> infeasible to fix in software), that option would do nothing (beyond any
> architecture-independent effects it might have such as implying
> -fno-fast-math).
I'm fine with `-fieee'/`-fno-ieee', and corresponding
`--with-ieee=yes/no' configuration options.
I have been aware of the Alpha processor's imprecise IEEE 754 exception
mode and while working on the specification concerned here I had in my
mind the possibility of expanding the semantics of the MIPS target's
`-mieee=' option to cover the somewhat similar imprecise IEEE 754
exception mode of the MIPS R8000 processor, or any optimisations of the
same or a different kind the MIPS architecture might introduce in the
future.
Since (regrettably) by now the Alpha architecture has become a legacy one
I didn't consider it important enough to create a generic option which
would only control the Alpha target, in addition to the MIPS target being
considered here. So I am actually glad you proposed it as I agree it will
make things cleaner.
> > As you may see in the GCC patches I have just posted the `-mieee=strict'
> > option I've implemented sets `-fno-fast-math', and `-mrelaxed-nan=none',
> > the only target-specific option so far. So this does exactly what I
> > outlined above.
>
> I am doubtful about the architecture-specific option setting
> architecture-independent options here. Having it the other way round as I
> suggested above would make more sense to me.
Agreed, as noted above.
> > "Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to produce strictly compliant code,
> > which in the context of this specification is defined as: following IEEE
> > Std 754 as closely as the programming language binding to the standard
> > (defined in the relevant language standard), the compiler implementation
> > and target hardware permit. This means the use of this option may affect
> > code produced in ways beyond NaN representation only."
> >
> > > > Does this answer address your concerns?
> > >
> > > No, the option concept as described seems too irremediably vague.
> >
> > Does this explanation give you a better idea of what I have in mind? Do
> > you still have concerns about the feasibility of the idea?
>
> It's better defined, but I think it would be better for -fieee to imply
> -mieee=strict -fno-fast-math (or whatever) rather than for -mieee=strict
> to imply architecture-independent options. Cf. i386 and sh where
> -ffinite-math-only affects architecture-specific options.
Thanks for the references. I'll have a look in the course of updating
the implementation.
With `-fieee' in the picture I think we can get rid of GCC's
target-specific high-level `-mieee=' option, as having become redundant,
and retain the low-level `-mrelaxed-nan=' only, with the assumption that
only power users will need to control this setting directly and they will
necessarily have studied and understood all the implications. Additional
low-level options can be added in the future as needed to control the
R8000 exception mode or other architectural features affecting IEEE 754
arithmetic, wired to `-fieee' as appropriate.
I'm going to retain the assembler and linker options and directives of
the `*ieee*' form though as their purpose is a bit different -- to set
flags in a binary file rather than affecting code generation -- and I
don't think it makes sense to expand the namespace there. The effects of
these options are cumulative rather than mutually exclusive and it's the
names of individual bits or enumeration fields within binary file's
control structures, referred in the option's or directive's argument, that
tell features apart.
I'll be updating the specification and the proposed implementation
shortly, and I also think the addition of `-fieee' will then better be
done as a separate preparatory change, initially affecting the Alpha
target only. Please let me know if I missed anything, or if you have any
other questions or comments.
Thank you for your input, and Happy New Year!
Maciej
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-01-07 0:55 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-14 10:42 [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking Maciej W. Rozycki
2015-11-14 10:42 ` Maciej W. Rozycki
2015-11-14 16:06 ` Cary Coutant
2015-11-16 8:56 ` Maciej W. Rozycki
2015-11-16 8:56 ` Maciej W. Rozycki
2015-11-17 15:07 ` Joseph Myers
2015-11-17 15:07 ` Joseph Myers
2015-11-20 17:16 ` Maciej W. Rozycki
2015-11-20 17:16 ` Maciej W. Rozycki
2015-11-20 18:25 ` Joseph Myers
2015-11-20 18:25 ` Joseph Myers
2015-11-27 15:47 ` Maciej W. Rozycki
2015-11-27 15:47 ` Maciej W. Rozycki
2015-11-27 18:03 ` Joseph Myers
2015-11-27 18:03 ` Joseph Myers
2016-01-07 0:55 ` Maciej W. Rozycki
2016-01-07 0:55 ` Maciej W. Rozycki
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.