fenv support vs. SMP systems

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

fenv support vs. SMP systems

Sebastian Huber-4
Hello,

the new fenv support alters usually some floating-point status and
control register. This register is usually specific to the processor
executing the code. In an SMP system, the current approach can lead to
an inconsistent system if the register is not included in the thread
context (for example in RTEMS these registers are considered to be
system wide and are only initialized during the system startup). What do
I mean with inconsistent system? For example, you set the rounding mode
on processor A to from X (= default) to Y, then the you migrate to
processor B and suddenly use the default rounding mode X. Another
example is to do a division by zero on processor A and then migrate to
processor B and check the exception flags.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Reply | Threaded
Open this post in threaded view
|

Re: fenv support vs. SMP systems

Joel Sherrill
On Mon, Jul 13, 2020 at 1:19 AM Sebastian Huber <
[hidden email]> wrote:

> Hello,
>
> the new fenv support alters usually some floating-point status and
> control register. This register is usually specific to the processor
> executing the code. In an SMP system, the current approach can lead to
> an inconsistent system if the register is not included in the thread
> context (for example in RTEMS these registers are considered to be
> system wide and are only initialized during the system startup). What do
> I mean with inconsistent system? For example, you set the rounding mode
> on processor A to from X (= default) to Y, then the you migrate to
> processor B and suddenly use the default rounding mode X. Another
> example is to do a division by zero on processor A and then migrate to
> processor B and check the exception flags.
>

That's all true and unfortunately well beyond the definition of fenv():

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html

It uses the term "application" and does not use either "process" or
"thread".

The C99 standard has more text but doesn't seem to add anything in this
area. This is from the introductory paragraph but doesn't add much:

""The floating-point environment refers
collectively to any floating-point status flags and control modes supported
by the
implementation.178) A floating-point status flag is a system variable whose
value is set
(but never cleared) when a floating-point exception is raised, which occurs
as a side effect
of exceptional floating-point arithmetic to provide auxiliary
information.179) A floating point
control mode is a system variable whose value may be set by the user to
affect the
subsequent behavior of floating-point arithmetic."

It does use the term "system variable" but that doesn't scope it to process
or
thread.

I hope the control register is at least part of the RTEMS FP context switch
area on all ports. At least then the POSIX term "application" is "thread".

Searching for implementations, I saw no hint that any implementation on
any architecture for an open source OS addressed anything beyond
setting the floating point environment for a thread.

If there is any practice that addresses even an entire process, I am unaware
of it.

--joel

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : [hidden email]
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
Reply | Threaded
Open this post in threaded view
|

Re: fenv support vs. SMP systems

Joseph Myers
On Mon, 13 Jul 2020, Joel Sherrill wrote:

> It does use the term "system variable" but that doesn't scope it to
> process or thread.

C11 (the first version of ISO C to introduce threads) says "The
floating-point environment has thread storage duration. The initial state
for a thread’s floating-point environment is the current state of the
floating-point environment of the thread that creates it at the time of
creation.".

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: fenv support vs. SMP systems

Joel Sherrill
On Mon, Jul 13, 2020, 12:17 PM Joseph Myers <[hidden email]> wrote:

> On Mon, 13 Jul 2020, Joel Sherrill wrote:
>
> > It does use the term "system variable" but that doesn't scope it to
> > process or thread.
>
> C11 (the first version of ISO C to introduce threads) says "The
> floating-point environment has thread storage duration. The initial state
> for a thread’s floating-point environment is the current state of the
> floating-point environment of the thread that creates it at the time of
> creation.".
>

Thanks Jim. This really clarifies things. It is unfortunate that POSIX has
threads but ignores them in defining behaviour in places.

Sounds like ensuring the floating point context includes whatever is
required for the floating point environment to persevere across thread
context switches and migrations in an SMP system.

Is this worth a note in the documentation?

--joel

>
> --
> Joseph S. Myers
> [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: fenv support vs. SMP systems

Sebastian Huber-4
In reply to this post by Joseph Myers
On 13/07/2020 19:16, Joseph Myers wrote:

> On Mon, 13 Jul 2020, Joel Sherrill wrote:
>
>> It does use the term "system variable" but that doesn't scope it to
>> process or thread.
> C11 (the first version of ISO C to introduce threads) says "The
> floating-point environment has thread storage duration. The initial state
> for a thread’s floating-point environment is the current state of the
> floating-point environment of the thread that creates it at the time of
> creation.".

Thanks for the clarification. Now I remember that I added this
information to the RISC-V ABI description some time ago:

https://github.com/riscv/riscv-elf-psabi-doc/commit/bd8211964c20fbbc96fff743684f04e86732d1e5#diff-b74abb1c6b89ba2de7129c8fbae8bd11