public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* fenv support vs. SMP systems
@ 2020-07-13  6:19 Sebastian Huber
  2020-07-13 13:00 ` Joel Sherrill
  0 siblings, 1 reply; 5+ messages in thread
From: Sebastian Huber @ 2020-07-13  6:19 UTC (permalink / raw)
  To: Newlib

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  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: fenv support vs. SMP systems
  2020-07-13  6:19 fenv support vs. SMP systems Sebastian Huber
@ 2020-07-13 13:00 ` Joel Sherrill
  2020-07-13 17:16   ` Joseph Myers
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Sherrill @ 2020-07-13 13:00 UTC (permalink / raw)
  To: Sebastian Huber; +Cc: Newlib, Eshan Dhawan

On Mon, Jul 13, 2020 at 1:19 AM Sebastian Huber <
sebastian.huber@embedded-brains.de> 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  : sebastian.huber@embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: fenv support vs. SMP systems
  2020-07-13 13:00 ` Joel Sherrill
@ 2020-07-13 17:16   ` Joseph Myers
  2020-07-13 21:03     ` Joel Sherrill
  2020-07-14  5:16     ` Sebastian Huber
  0 siblings, 2 replies; 5+ messages in thread
From: Joseph Myers @ 2020-07-13 17:16 UTC (permalink / raw)
  To: Joel Sherrill; +Cc: Sebastian Huber, Newlib

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
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: fenv support vs. SMP systems
  2020-07-13 17:16   ` Joseph Myers
@ 2020-07-13 21:03     ` Joel Sherrill
  2020-07-14  5:16     ` Sebastian Huber
  1 sibling, 0 replies; 5+ messages in thread
From: Joel Sherrill @ 2020-07-13 21:03 UTC (permalink / raw)
  To: Joseph Myers; +Cc: Sebastian Huber, Newlib

On Mon, Jul 13, 2020, 12:17 PM Joseph Myers <joseph@codesourcery.com> 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
> joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: fenv support vs. SMP systems
  2020-07-13 17:16   ` Joseph Myers
  2020-07-13 21:03     ` Joel Sherrill
@ 2020-07-14  5:16     ` Sebastian Huber
  1 sibling, 0 replies; 5+ messages in thread
From: Sebastian Huber @ 2020-07-14  5:16 UTC (permalink / raw)
  To: Joseph Myers, Joel Sherrill; +Cc: Newlib

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-07-14  5:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-13  6:19 fenv support vs. SMP systems Sebastian Huber
2020-07-13 13:00 ` Joel Sherrill
2020-07-13 17:16   ` Joseph Myers
2020-07-13 21:03     ` Joel Sherrill
2020-07-14  5:16     ` Sebastian Huber

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).