mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Damian McGuckin <damianm@esi.com.au>
To: musl@lists.openwall.com
Subject: Re: [musl] Considering x86-64 fenv.s to C
Date: Fri, 24 Jan 2020 11:42:02 +1100 (AEDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.2001240755500.28245@key0.esi.com.au> (raw)
In-Reply-To: <20200118094015.GE23985@port70.net>


In an attempt to address this issue, the following can be considered an 
attempt at a 'discussion paper'.

The following are assumptions. Whether the assumptions are valid enough
is debatable and open for discussion by virtue of this initial post. I
will put the generic details and once there is some agreement to that,
the details can be attacked, including nomenclature.  The names are not
locked in stone. They are just what is being used to illustrate the design.
Comments relating to accepted practice in MUSL are welcome.

These assumptions do not hold for i386, x32, and x86_64, for reasons that 
are largely a need to address their historical origins which at the time, 
were quite ground breaking. The 3 architectures need their own special 
handling although background research suggest that all three can be made 
generic with respect to each.  But that is another story.

I have written this at a level that was meant to be read by those with a
low level of knowledge. That may be a mistake but it meant that I could
get some level of initial peer review before posting this to the list!

Ignoring Intel FPUs for the moment at least, it is assumed that all FPUs 
expose their state to, and allow control of themselves by, user programs 
through

a) a status register which contains bits which are set when a floating
    point exception occurs, the exception bits, and
b) a control register which contains a bit field in which is stored the
    currently active rounding mode.

These registers may be one and the same.  It is assumed that they can be
stored in, or loaded from an unsigned int (of 32-bits).  This appears to
be the case for all considered architectures (see the list below).

The interrogation and modification of both the status register and the
control register can be done via the respective pair of 'routines'

 	getsr/setsr
and
 	getcr/setcr

which respectively copies the register's contents into a local variable,
an unsigned int, and sets the register's contents from its unsigned int
argument.

These are simple #defines, being mapped to

a)	if the status and control bits are in the same register, one of

 	   static inline unsigned int get_csr() { .... }
 	   static inline void set_csr(unsigned int csr) { .... }

 	where get_csr is mapped to both 'getsr' and 'getcr' and

a)	if the registers are in fact distinct, one

 	    static inline unsigned int get_sr() { .... }
 	    static inline void set_sr(unsigned int csr) { .... }
 	    static inline unsigned int get_cr() { .... }
 	    static inline void set_cr(unsigned int csr) { .... }

There exists a 'const' default floating point environment which can be
defined as a local variable as:

      const fenv_t fe_dfl_env = FE_DFL_ENV_DATA;

where FE_DFL_ENV_DATA is a #define which is created automatically if the
variable 'fe_dfl_env' is an unsigned int.

There also exists a pair of macros, 'gete' and 'sete', and an assumed
memory object '*e' which are defined such that

 	#define gete(e)	... // extracts the FPU's environment into *e

 	#define sete(e)	... // replaces the FPU's environment with *e

 	fenv_t *e;

Some examples of these architecture dependent routines and the associated 
definitions were crafted for m68k, powerpc64, and s390x, by copying the 
appropriate bits from how 'musl' currently does it.  An approximation for 
examples for sparc64, mips64 and sh is provides, remembering that these 
are approximations only.  The implementation for these cases is likely to 
be at least less than optimal if not wrong.  Please amend as appropriate.

Also, at least one architecture has an expanded idea of the concept of an
INVALID exception. For such scenarios, 'feclearexcept' and 'feraiseexcept'
need macros to be defined which massage the exceptions bits 'excepts' that
come a user's program, respectively

     #define FE_QUALIFY_CLEAR_EXCEPT(excepts)	....
and
     #define FE_QUALIFY_RAISE_EXCEPT(excepts)	....

For any other scenarios, these macros never need to be defined explicitly,
the code will define them as empty by itself.
All routines validate the exceptions bits 'excepts' coming a user's program.
This is achieve with a macro, the default of which is

     #define FE_VALIDATE_EXCEPT(except)	except &= FE_ALL_EXCEPTS

This simply discards any bits which are not a valid exception bit. It is
created automatically and does not need to be defined. However, where such
an approach for the case of illegal exceptions is deemed to unsatisfactory
and for example routine failure and a non-zero return is deems a better
approach, that macro can redefined explicitly as

    #define FE_VALIDATE_EXCEPT(except) if ((except) & FE_ALL_EXCEPTS) return(-1)

Historically it seems only one architecture took this approach, 'm68k',
and then only on Linux.  On any other architecture, and on *BSD, the
earlier, the default approach is used.

An attempt at an implementation is shown below, WITHOUT the architecture 
dependent macro definitions and 'static inline' routines which largely 
just comprise one line of embedded assembler.

Note that raising exceptions is done with arithmetic expression for trivial
cases and by directly modifying the floating point status register for the
non-trivial case.  The approach is open to question. While it allows testing
in isolation, it does not use any of the latest barrier function approaches
and routines like 'math_uflow' and colleagues.  It might be advantages to
focus on the overall design first and then discuss how to raise exceptions
later so as to not detract from the discussion of the overall design of the
generic interface.

Please consider:

/*
  * default inspection and modification of FPU status and control registerd
  */
#ifndef getcr
#define getcr   get_csr
#endif
#ifndef setcr
#define setcr   set_csr
#endif
#ifndef getsr
#define getsr   get_csr
#endif
#ifndef setsr
#define setsr   set_csr
#endif
#ifdef FE_DFL_ENV_DATA
#define FE_DFL_ENV_DATA 0	/* assume this is a unsigned int - cast?? */
#endif
#ifndef gete
#define gete(e) *e = get_csr()	/* assume this is a basic type */
#endif
#ifndef sete
#define sete(e) set_csr(*e)	/* assume this is a basic type */
#endif
#ifndef FE_ALL_EXCEPT
#define FE_VALID_EXCEPT (FE_INEXACT|FE_DIV_BY_ZERO|FE_UNDERFLOW|FE_OVERFLOW)
#define FE_ALL_EXCEPT   (FE_INVALID|FE_VALID_EXCEPT)
#endif
/*
  * The usual approach to validating an exception mask is to throw out
  * anything which is illegal. Some systems will NOT do this, choosing
  * instead to return a non-zero result on encountering an illegal mask
  */ 
#ifndef FE_VALIDATE_EXCEPT
#define FE_VALIDATE_EXCEPT(e)   e &= FE_ALL_EXCEPT
#endif
/*
  * There is usually no need to mess the generic valid exceptions bits
  * given to 'feclearexcept' and 'feraiseexcept' so define a 'nothing'
  * macro for such a scenario - is this the MUSL accepted style????
  */
#ifndef FE_QUALIFY_CLEAR_EXCEPT
#define FE_QUALIFY_CLEAR_EXCEPT(excepts)    (0)
#endif
#ifndef FE_QUALIFY_RAISE_EXCEPT
#define FE_QUALIFY_RAISE_EXCEPT(excepts)    (0)
#endif
/*
  * Compute the rounding mask with some rigid logic
  */
#ifndef FE_TO_NEAREST
#define FE_TO_NEAREST   0
#define ROUND_MASK  ((unsigned int) 0)
#else
#ifndef FE_TOWARDS_ZERO
#define ROUND_MASK  ((unsigned int) 0)
#else
#ifdef  FE_DOWNWARD
#ifdef  FE_UPWARD
#define ROUND_MASK  ((unsigned int) (FE_DOWNWARD|FE_UPWARD|FE_TOWARDZERO))
#else
#define ROUND_MASK  UNSUPPORTED rounding
#endif
#else
#ifdef  FE_UPWARD
#define ROUND_MASK  UNSUPPORTED rounding
#else
#define ROUND_MASK  ((unsigned int) (FETOWARDZERO))
#endif
#endif
#endif
#endif

int
feclearexcept(excepts)
{
     FE_VALIDATE_EXCEPT(excepts);
     FE_QUALIFY_CLEAR_EXCEPT(excepts);
     setsr(getsr() & ~((unsigned int) excepts));
     return(0);
}

static inline int
__raisearithmetically(int excepts)
{
     /*
      * assume single OP is faster than double OP
      */
     const float one = (float) 1;
     const float zero = (float) 0;
     const float tiny = (float) 0x1.0p-126;
     const float huge = (float) 0x1.0p+126;
     volatile float x;

     /*
      * if it is just a simple exception, arithmetic expressions are optimal
      */
     switch(excepts)
     {
     case FE_INVALID:
         x = zero, x /= x;
         break;
     case FE_DIVBYZERO:
         x = zero, x = one / x;
         break;
     case FE_INEXACT:
         x = tiny, x += one;
         break;
     case (FE_OVERFLOW | FE_INEXACT):
         x = huge, x *= x;
         break;
     case (FE_UNDERFLOW | FE_INEXACT):
         x = tiny, x *= x;
         break;
     default: /* if more than one exception exists, a sledgehammer is viable */
         setsr(getsr() | ((unsigned int) excepts));
         break;
     }
     return(0);
}

int
feraiseexcept(int excepts)
{
     FE_VALIDATE_EXCEPT(excepts);
     FE_QUALIFY_RAISE_EXCEPT(excepts);
     return __raisearithmetically(excepts);
}

int
fetestexcept(int excepts)
{
     FE_VALIDATE_EXCEPT(excepts);

     return (int) (getsr() & ((unsigned int) excepts));
}

int
fegetround(void)
{
     return (int) (getcr() & ROUND_MASK);
}

int
fesetround(int rounding_mode)
{
     if ((rounding_mode & ~ROUND_MASK) == 0)
     {
         unsigned int mode = ((unsigned int) rounding_mode);

         return (setcr((getcr() & ~ROUND_MASK) | (mode & ROUND_MASK)), 0);
     }
     return(-1);
}

int
fegetenv(fenv_t *envp)
{
     return ((gete(envp)), 0);
}

int
fesetenv(fenv_t *envp)
{
     fenv_t envpd = FE_DFL_ENV_DATA, *e = envp == FE_DFL_ENV ? &envpd : envp;

     return ((sete(envp)), 0);
}

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

  reply	other threads:[~2020-01-24  0:42 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16  4:30 Damian McGuckin
2020-01-16 15:11 ` Markus Wichmann
2020-01-16 16:14 ` Rich Felker
2020-01-16 18:56   ` Damian McGuckin
2020-01-16 19:33     ` Rich Felker
2020-01-16 21:31       ` Damian McGuckin
2020-01-17  3:36       ` Damian McGuckin
2020-01-17  3:48         ` Damian McGuckin
2020-01-17  3:53         ` David Edelsohn
2020-01-17 14:13           ` Rich Felker
2020-01-17 14:19             ` David Edelsohn
2020-01-17 14:53         ` Rich Felker
2020-01-18  4:45           ` Damian McGuckin
2020-01-18  5:29             ` Rich Felker
2020-01-19  8:50               ` Damian McGuckin
2020-01-19  9:07           ` Damian McGuckin
2020-01-19 10:42             ` Szabolcs Nagy
2020-01-19 12:25               ` Damian McGuckin
2020-01-20  5:32           ` Damian McGuckin
2020-01-20 17:38             ` Rich Felker
2020-01-20 21:11               ` [musl] Triggering Overflow (or Underflow) without triggering Inexact on i386 Damian McGuckin
2020-01-20 22:32                 ` Szabolcs Nagy
2020-01-21  3:53           ` [musl] Considering x86-64 fenv.s to C Damian McGuckin
2020-01-21  4:22             ` Rich Felker
2020-01-21  4:46               ` Damian McGuckin
2020-01-21  7:26                 ` Damian McGuckin
2020-01-17 16:41         ` Markus Wichmann
2020-01-18  1:15           ` Szabolcs Nagy
2020-01-18  5:03             ` Damian McGuckin
2020-01-18  5:37               ` Rich Felker
2020-01-18  9:40                 ` Szabolcs Nagy
2020-01-24  0:42                   ` Damian McGuckin [this message]
2020-01-24  1:11                     ` Rich Felker
2020-01-24  4:13                       ` Damian McGuckin
2020-01-24  4:55                         ` Rich Felker
2020-01-24  6:08                           ` Damian McGuckin
2020-01-24 13:44                             ` Rich Felker
2020-01-24 14:45                               ` Damian McGuckin
2020-01-24 23:59                               ` Damian McGuckin
2020-01-25  0:11                                 ` Rich Felker
2020-01-26  3:28                                   ` Damian McGuckin
2020-01-26  3:28                                   ` Damian McGuckin
2020-01-26  3:30                                   ` Damian McGuckin
2020-01-26  3:32                                   ` Damian McGuckin
2020-01-26  5:25                                   ` Damian McGuckin
2020-01-27  3:32                                   ` Damian McGuckin
2020-01-27  5:39                                   ` Damian McGuckin
2020-02-02  0:47                                   ` Damian McGuckin
2020-02-03  0:54                                   ` Damian McGuckin
2020-02-03  2:09                                     ` Rich Felker
2020-02-03  2:12                                       ` Damian McGuckin
2020-02-22 20:17                                         ` Rich Felker
2020-02-22 20:53                                           ` Damian McGuckin
2020-02-23  5:41                                           ` Damian McGuckin
2020-02-23  6:25                                             ` Rich Felker
2020-02-23  8:35                                               ` Damian McGuckin
2020-02-07 21:25                                   ` Damian McGuckin
2020-02-07 21:38                                     ` Rich Felker
2020-02-07 23:53                                       ` Damian McGuckin
2020-02-09  5:04                                       ` Damian McGuckin
2020-01-24  7:10                           ` Damian McGuckin
2020-01-18  5:04             ` Markus Wichmann
2020-02-03 14:16 [musl] PPC64(LE) support in musl requires ALTIVEC Romain Naour
2020-02-03 14:50 ` Rich Felker
2020-02-05  1:32   ` [musl] Considering x86-64 fenv.s to C Damian McGuckin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.02.2001240755500.28245@key0.esi.com.au \
    --to=damianm@esi.com.au \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).