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, 17 Jan 2020 14:36:20 +1100 (AEDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.2001171401570.27694@key0.esi.com.au> (raw)
In-Reply-To: <20200116193343.GP30412@brightrain.aerifal.cx>


Feedback/Discussion please, especially in terms of what extra comments I 
need to make?  I hope I have not missed anything.

General Comments
****************

Except where noted, the approach taken to invalid input is to mask out the 
invalid data, use what data is left, and never inform the calling program 
of invalid data.

The i386(sometimes), X32 and X86-64 generally need to realise that they 
have both the X87 FPU and the SSE.  Are there scenarios where this will 
not be the case or do we need to plan for future scenarious where this 
will not be the case?

Do we need to consider what is in the latest IEEE 754 2019 standard to see 
what enhancements are needed or just wait for C2X?

Other Architectures
*******************

Should we look at what is needed for Sparc and Power9 to ensure that the 
(eventually-) chosen abstraction will work with these? Are there any other 
chips which need to be considered. If you look at more recent chipset 
designs, they have all been able to leverage the experience of working 
with IEEE 754 exceptions and rounding and follow the same style of use of 
an exception status and round control register . So I think catering for 
the current crop, plus those 2 mentioned above, should be adequate. But
am I wrong?

Is Power9 the same as PowerPC64?  I have never seen one. I know I do not 
know enough about this chip as the 128-bit floating point discussion talks 
about Rounding-To-Odd mode? I have tried to read the 1358 pages of the ISA 
3.0 architecture manual but I have a long way to go before I know even 10% 
of what is in there. Are the newer beefy ARMS likely to change what they
do not in the context of 'fenv' routines?

Also, and I could be wrong, currently MUSL assumes that there is an 
integral type for every floating type.  On some architectures, I believe 
this is not always the case for 128-bit floating point numbers. On some 
Sparcs, I am not sure it was even the case for 64-bit numbers but that was 
a long time. I do not think that this restriction will influence anything 
here.  How it affects MUSL in general is another question irrelevant to 
this discussion.

Summary
*******

aarch64 (arm)

*	All assembler

arm (bare)

*	Empty

i386

*	All assembler

*	The fldenv instruction to update the status registers has a serious
 	overhead which cannot be avoided in 'feraiseexcept'. No attempt is
 	made to optimize any unnecessary usage (as occurs in feclearexcept).
 	Note that fldenv also makes the 'feclearexcept' routine unavoidably
 	complex.

*	What is the best way to query '__hwcap' from inline __asm__ statement,
 	specifically to verify if SSE instructions have to be supported

m68k

*	In C.

*	Very clear

*	feclearexcept and feraiseexcept

 		if (exception_mask & ~FE_ALL_EXCEPT) return (-1)

 	Different to the way others handle invalid input. Is this cast
 	behaviour cast in stone based on standard documentation?

mips/mips64/mipsn32

*	All assembler

*	Not overly complex.

powerpc

*	All assembler

*	I think that this architecture has more exception bits than IEEE 754
 	specifies. It has lots of specific cases of FE_INVALID. This needs
 	to be considered when dealing with FE_INVALID.

*	My knowledge of this assembler is poor. Please expand these comments!!

powerpc64

*	In C.

*	Very clear

*	Note that this architecture has more exception bits than IEEE 754
 	specifies. It has lots of specific cases of FE_INVALID. This needs
 	to be considered when dealing with FE_INVALID.

*	This is the first time I have seen this style of coding to cast a
 	double to a union and then extract the data as a long.

 		return (union {double f; long i;}) {get_fpscr_f()}.i;

 	Is this style of coding universally accepted within MUSL? From my
 	reading of other routines, it is normally done as

 		union {double f; long i;} f = { get_fpscr_f() };

 		return f.i;

 	Just curious.

riscv64

*	All assembler.

*	Very clear.

*	The architecture has obviously been done after a review of lots
 	of experience with the IEEE 754 standard.

s390x

*	In C.

*	Very clear.

*	Why is __fesetround(int) 'hidden'? Where is fesetround()?

sh (SuperH??)

*	In assembler

*	I know zero about this assembler

*	There is some pecularity about updating the environment. I have no
 	idea what is going on here. Anybody clear to elaborate?

x32

*	In assembler

*	Why does 'feclearexcept' disrespect the flags by clearing ALL x86 bits?

*	It is this really much the same as x86-64 (or am I wrong)?

x86_64

*	In assembler

*	Why does 'feclearexcept' disrespect the flags by clearing ALL x86 bits?

*** FINISH

  parent reply	other threads:[~2020-01-17  3:36 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 [this message]
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
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.2001171401570.27694@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).