Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #110403 > unrolled thread

Calling conventions (particularly 32-bit ARM)

Back to article view | Back to comp.arch

Contents

  Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-06 14:57 +0100
    Re: Calling conventions (particularly 32-bit ARM) Theo <theom+news@chiark.greenend.org.uk> - 2025-01-06 15:23 +0000
      Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-07 09:22 +0100
    Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 15:32 +0000
      Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 20:19 +0000
        Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-07 10:09 +0100
          Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 23:23 +0000
            Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 23:35 +0000
              Re: Calling conventions (particularly 32-bit ARM) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-07 15:42 -0800
                Re: Calling conventions (particularly 32-bit ARM) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-07 20:01 -0800
              Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-08 01:38 +0000
      Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-07 09:49 +0100
    Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 20:10 +0000
      Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-07 02:11 +0000
        Re: Calling conventions (particularly 32-bit ARM) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-07 06:53 +0000
        Re: Calling conventions (particularly 32-bit ARM) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-12 12:10 -0800
          Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-12 20:41 +0000
          Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-13 01:20 +0000
            Re: Calling conventions (particularly 32-bit ARM) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-14 09:40 -0800
              Re: Calling conventions (particularly 32-bit ARM) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-14 19:18 +0100
                Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-14 23:48 +0200
                  Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 23:27 +0000
                    Re: Calling conventions (particularly 32-bit ARM) John Levine <johnl@taugh.com> - 2025-01-15 03:31 +0000
                      Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-15 16:50 +0000
                        Re: Calling conventions (particularly 32-bit ARM) John Levine <johnl@taugh.com> - 2025-01-15 22:03 +0000
                    Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-16 03:02 +0000
                      Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 15:08 +0000
                        Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-16 16:24 +0000
          Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-13 21:33 +0000
            Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 06:48 +0000
              Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 18:03 +0000
      Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2025-01-07 16:52 -0500
        Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-08 12:20 -0500
          Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-09 08:38 +0000
            Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-13 10:55 -0500
        Re: Calling conventions (particularly 32-bit ARM) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:09 -0800
          Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2025-01-28 22:53 -0500
            Re: Calling conventions (particularly 32-bit ARM) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-14 20:40 -0800
              Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2026-02-17 15:35 -0500
                Re: Calling conventions (particularly 32-bit ARM) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-14 09:34 -0700
                  Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2026-03-24 17:20 -0400
      Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-08 12:34 -0500
        Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-08 20:19 +0000
        Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-08 22:08 +0000
          Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-08 18:20 -0500
            Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-09 00:11 +0000
            Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-09 07:23 +0000
              Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-09 10:07 +0000
                Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-10 08:24 +0000
              Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-09 20:48 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-09 21:23 +0000
                  Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-10 01:08 +0000
                    Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-10 09:19 +0000
              Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-10 08:33 +0000
                Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-10 10:25 +0000
                  Re: Calling conventions (particularly 32-bit ARM) John Levine <johnl@taugh.com> - 2025-01-10 15:17 +0000
                  Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-13 02:10 +0000
                    Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-13 14:19 +0000
                    Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-13 18:02 +0000
                      Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-13 19:00 +0000
                        Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-13 21:53 +0000
                          Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-13 22:02 +0000
                            Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-13 22:40 +0000
                              Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 02:32 +0000
                                Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-14 15:08 +0100
                                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 14:22 +0000
                                  Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-14 16:41 +0200
                                    Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-14 18:02 +0000
                                  Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 18:15 +0000
                                  Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 18:19 +0000
                                    Re: Calling conventions (particularly 32-bit ARM) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-14 19:39 +0100
                                      Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 19:14 +0000
                                      Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 20:01 +0000
                                        Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 22:05 +0000
                                          Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 15:23 -0800
                                            Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 23:39 +0000
                                              Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 16:59 -0800
                                            Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 23:40 +0000
                                              Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 17:11 -0800
                                      Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-15 00:09 +0200
                                    Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 19:08 +0000
                                    Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 19:24 +0000
                                      Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 20:31 +0000
                                        Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-14 23:13 +0200
                                          Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-15 00:47 +0000
                              Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 06:20 +0000
                              Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-14 15:05 +0100
                                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 14:39 +0000
                                  Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-14 16:50 +0100
                                    Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 15:32 -0800
                          Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 00:14 -0800
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-10 14:43 +0000
              Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-10 18:39 +0100
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-10 18:39 +0000
                  Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-12 14:55 +0100
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-10 19:19 +0000
                  Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-12 14:59 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#110485

mitchalsup@aol.com (MitchAlsup1) writes:
>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>
>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>
>>> errno is an atrocity all by itself; single handedly preventing
>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>> as instructions.
>>
>> Fortunately, the C standard does not require errno to be set
>> for these functions.  Apple, for example, does not do so.
>
>Nor will I.

POSIX does, however, require errno to be set conditionally
based on an application global variable 'math_errhandling'.

[toc] | [prev] | [next] | [standalone]

#110486

On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>>
>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>
>>>> errno is an atrocity all by itself; single handedly preventing
>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>>> as instructions.
>>>
>>> Fortunately, the C standard does not require errno to be set
>>> for these functions.  Apple, for example, does not do so.
>>
>>Nor will I.
>
> POSIX does, however, require errno to be set conditionally
> based on an application global variable 'math_errhandling'.

The functions mentioned have the property of taking x as
any IEEE 754 number (including NaNs, infinities, denorms)
and produce a IEEE 754 number {NaNs, infinities, norms,
denorms}.

But if POSIX wants to spend as many cycles setting errno
as performing the calculation, that is for POSIX to decide.

But with functions that take 754 arguments and produce 754
results, it seems unnecessary.

[toc] | [prev] | [next] | [standalone]

#110487

mitchalsup@aol.com (MitchAlsup1) writes:
>On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>>>
>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>>
>>>>> errno is an atrocity all by itself; single handedly preventing
>>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>>>> as instructions.
>>>>
>>>> Fortunately, the C standard does not require errno to be set
>>>> for these functions.  Apple, for example, does not do so.
>>>
>>>Nor will I.
>>
>> POSIX does, however, require errno to be set conditionally
>> based on an application global variable 'math_errhandling'.
>
>The functions mentioned have the property of taking x as
>any IEEE 754 number (including NaNs, infinities, denorms)
>and produce a IEEE 754 number {NaNs, infinities, norms,
>denorms}.
>
>But if POSIX wants to spend as many cycles setting errno
>as performing the calculation, that is for POSIX to decide.

POSIX leaves it up to the programmer to decide.  If the
programmer desires EDOM or ERANGE, they set the
appropriate bit in math_errhandling before calling the
sin et alia functions.

[toc] | [prev] | [next] | [standalone]

#110488

On Mon, 13 Jan 2025 22:40:02 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
>>
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>>>>
>>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>>>
>>>>>> errno is an atrocity all by itself; single handedly preventing
>>>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>>>>> as instructions.
>>>>>
>>>>> Fortunately, the C standard does not require errno to be set
>>>>> for these functions.  Apple, for example, does not do so.
>>>>
>>>>Nor will I.
>>>
>>> POSIX does, however, require errno to be set conditionally
>>> based on an application global variable 'math_errhandling'.
>>
>>The functions mentioned have the property of taking x as
>>any IEEE 754 number (including NaNs, infinities, denorms)
>>and produce a IEEE 754 number {NaNs, infinities, norms,
>>denorms}.
>>
>>But if POSIX wants to spend as many cycles setting errno
>>as performing the calculation, that is for POSIX to decide.
>
> POSIX leaves it up to the programmer to decide.  If the
> programmer desires EDOM or ERANGE, they set the
> appropriate bit in math_errhandling before calling the
> sin et alia functions.

So, now the subroutine, which computes all work in a single
instruction, has to check a global variable to decide if it
has to LD in TLS pointer just to set errno ?!!?

[toc] | [prev] | [next] | [standalone]

#110493

On 14/01/2025 03:32, MitchAlsup1 wrote:
> On Mon, 13 Jan 2025 22:40:02 +0000, Scott Lurndal wrote:
> 
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>> On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
>>>
>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>> On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>>>>>
>>>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>>>>
>>>>>>> errno is an atrocity all by itself; single handedly preventing
>>>>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>>>>>> as instructions.
>>>>>>
>>>>>> Fortunately, the C standard does not require errno to be set
>>>>>> for these functions.  Apple, for example, does not do so.
>>>>>
>>>>> Nor will I.
>>>>
>>>> POSIX does, however, require errno to be set conditionally
>>>> based on an application global variable 'math_errhandling'.
>>>
>>> The functions mentioned have the property of taking x as
>>> any IEEE 754 number (including NaNs, infinities, denorms)
>>> and produce a IEEE 754 number {NaNs, infinities, norms,
>>> denorms}.
>>>
>>> But if POSIX wants to spend as many cycles setting errno
>>> as performing the calculation, that is for POSIX to decide.
>>
>> POSIX leaves it up to the programmer to decide.  If the
>> programmer desires EDOM or ERANGE, they set the
>> appropriate bit in math_errhandling before calling the
>> sin et alia functions.
> 
> So, now the subroutine, which computes all work in a single
> instruction, has to check a global variable to decide if it
> has to LD in TLS pointer just to set errno ?!!?

Seems crazy to me too.

gcc at least has a "-fno-math-errono" flag that skips errno setting for 
maths functions that are executed as a single instruction.  That makes a 
big difference to things like "sqrt".

[toc] | [prev] | [next] | [standalone]

#110494

mitchalsup@aol.com (MitchAlsup1) writes:
>On Mon, 13 Jan 2025 22:40:02 +0000, Scott Lurndal wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
>>>
>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>>>>>
>>>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>>>>
>>>>>>> errno is an atrocity all by itself; single handedly preventing
>>>>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>>>>>> as instructions.
>>>>>>
>>>>>> Fortunately, the C standard does not require errno to be set
>>>>>> for these functions.  Apple, for example, does not do so.
>>>>>
>>>>>Nor will I.
>>>>
>>>> POSIX does, however, require errno to be set conditionally
>>>> based on an application global variable 'math_errhandling'.
>>>
>>>The functions mentioned have the property of taking x as
>>>any IEEE 754 number (including NaNs, infinities, denorms)
>>>and produce a IEEE 754 number {NaNs, infinities, norms,
>>>denorms}.
>>>
>>>But if POSIX wants to spend as many cycles setting errno
>>>as performing the calculation, that is for POSIX to decide.
>>
>> POSIX leaves it up to the programmer to decide.  If the
>> programmer desires EDOM or ERANGE, they set the
>> appropriate bit in math_errhandling before calling the
>> sin et alia functions.
>
>So, now the subroutine, which computes all work in a single
>instruction, has to check a global variable to decide if it
>has to LD in TLS pointer just to set errno ?!!?

The subroutine clearly does more than "do all the work in a single
instruction".

How does your instruction support all the functionality
required by the POSIX specification for the sin(3) library function?

https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html

Clearly there are programmers who wish to be able to detect
certain exceptions, and POSIX allows programmers to
select that behavior.

[toc] | [prev] | [next] | [standalone]

#110496

On Tue, 14 Jan 2025 14:22:19 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
> >On Mon, 13 Jan 2025 22:40:02 +0000, Scott Lurndal wrote:
> >  
> >> mitchalsup@aol.com (MitchAlsup1) writes:  
> >>>On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
> >>>  
> >>>> mitchalsup@aol.com (MitchAlsup1) writes:  
> >>>>>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
> >>>>>  
> >>>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
> >>>>>>  
> >>>>>>> errno is an atrocity all by itself; single handedly preventing
> >>>>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
> >>>>>>> as instructions.  
> >>>>>>
> >>>>>> Fortunately, the C standard does not require errno to be set
> >>>>>> for these functions.  Apple, for example, does not do so.  
> >>>>>
> >>>>>Nor will I.  
> >>>>
> >>>> POSIX does, however, require errno to be set conditionally
> >>>> based on an application global variable 'math_errhandling'.  
> >>>
> >>>The functions mentioned have the property of taking x as
> >>>any IEEE 754 number (including NaNs, infinities, denorms)
> >>>and produce a IEEE 754 number {NaNs, infinities, norms,
> >>>denorms}.
> >>>
> >>>But if POSIX wants to spend as many cycles setting errno
> >>>as performing the calculation, that is for POSIX to decide.  
> >>
> >> POSIX leaves it up to the programmer to decide.  If the
> >> programmer desires EDOM or ERANGE, they set the
> >> appropriate bit in math_errhandling before calling the
> >> sin et alia functions.  
> >
> >So, now the subroutine, which computes all work in a single
> >instruction, has to check a global variable to decide if it
> >has to LD in TLS pointer just to set errno ?!!?  
> 
> The subroutine clearly does more than "do all the work in a single
> instruction".
> 
> How does your instruction support all the functionality
> required by the POSIX specification for the sin(3) library function?
> 
> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
> 

I see no problems for as long as (math_errhandling & MATH_ERRNO)==0.
Which sounds like more sensible choice regardless of question of
instruction vs library.

> Clearly there are programmers who wish to be able to detect
> certain exceptions, and POSIX allows programmers to
> select that behavior.

Raising of FP exceptions is orthogonal to question of one instruction
vs library call. If anything, when exceptions are enabled, with
single-instruction implementation it is probably easier for exception
handler to find the reason and generate useful diagnostics.

As to what POSIX allows, on the manual page that you quoted I see no
indication that implementation is required to give to programmer to
select this or that behavior. I read it like implementation is allowed
to make the choice fully by itself.

[toc] | [prev] | [next] | [standalone]

#110500

Michael S <already5chosen@yahoo.com> writes:
>On Tue, 14 Jan 2025 14:22:19 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>> Clearly there are programmers who wish to be able to detect
>> certain exceptions, and POSIX allows programmers to
>> select that behavior.
>
>Raising of FP exceptions is orthogonal to question of one instruction
>vs library call. If anything, when exceptions are enabled, with
>single-instruction implementation it is probably easier for exception
>handler to find the reason and generate useful diagnostics.

It seems to me that "raise an exception" is in the IEEE 754 sense (by
default set a sticky flag in an internal register), not in the C sense
of raising a signal.  AFAIK you can tell the system to produce a
signal for some exceptions, but the default on Linux is not to.

>As to what POSIX allows, on the manual page that you quoted I see no
>indication that implementation is required to give to programmer to
>select this or that behavior. I read it like implementation is allowed
>to make the choice fully by itself.

And if it is friendly, it can give the programmer a compiler option to
select between the variants.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

[toc] | [prev] | [next] | [standalone]

#110501

On Tue, 14 Jan 2025 14:22:19 +0000, Scott Lurndal wrote:

> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Mon, 13 Jan 2025 22:40:02 +0000, Scott Lurndal wrote:
>>
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
>>>>
>>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>>>>On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>>>>>>
>>>>>>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>>>>>>
>>>>>>>> errno is an atrocity all by itself; single handedly preventing
>>>>>>>> direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
>>>>>>>> as instructions.
>>>>>>>
>>>>>>> Fortunately, the C standard does not require errno to be set
>>>>>>> for these functions.  Apple, for example, does not do so.
>>>>>>
>>>>>>Nor will I.
>>>>>
>>>>> POSIX does, however, require errno to be set conditionally
>>>>> based on an application global variable 'math_errhandling'.
>>>>
>>>>The functions mentioned have the property of taking x as
>>>>any IEEE 754 number (including NaNs, infinities, denorms)
>>>>and produce a IEEE 754 number {NaNs, infinities, norms,
>>>>denorms}.
>>>>
>>>>But if POSIX wants to spend as many cycles setting errno
>>>>as performing the calculation, that is for POSIX to decide.
>>>
>>> POSIX leaves it up to the programmer to decide.  If the
>>> programmer desires EDOM or ERANGE, they set the
>>> appropriate bit in math_errhandling before calling the
>>> sin et alia functions.
>>
>>So, now the subroutine, which computes all work in a single
>>instruction, has to check a global variable to decide if it
>>has to LD in TLS pointer just to set errno ?!!?
>
> The subroutine clearly does more than "do all the work in a single
> instruction".

All of the work of computing sin(x) is performed in a single
instruction.

So we have a subroutine that looks like::

double library_sin( double x )
{
     // the work
     double r = My_66000_sin(x);
     // along with setting the flag bits

     // the overhead
     if( FP_Classify( x, NaN | INFINITY | ... ) )
     {
         errno_p tls = TLS();
         if( FP_Classify( x, NaN )      tls->errno = errno_NaN;
         if( FP_Classify( x, INFINITY ) tls->errno = errno_infinity;
         ...
      }
      return r;
}

> How does your instruction support all the functionality
> required by the POSIX specification for the sin(3) library function?

Except for the setting of errno.

> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
>
> Clearly there are programmers who wish to be able to detect
> certain exceptions, and POSIX allows programmers to
> select that behavior.

[toc] | [prev] | [next] | [standalone]

#110503

Scott Lurndal <scott@slp53.sl.home> schrieb:

> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
>
> Clearly there are programmers who wish to be able to detect
> certain exceptions, and POSIX allows programmers to
> select that behavior.

Clearly, there is a committee which wanted to be able for people
to detect certain error conditions on a fine-grained level.
One assumes tht they did not consider the consequences.

[toc] | [prev] | [next] | [standalone]

#110504

Thomas Koenig wrote:
> Scott Lurndal <scott@slp53.sl.home> schrieb:
> 
>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
>>
>> Clearly there are programmers who wish to be able to detect
>> certain exceptions, and POSIX allows programmers to
>> select that behavior.
> 
> Clearly, there is a committee which wanted to be able for people
> to detect certain error conditions on a fine-grained level.
> One assumes tht they did not consider the consequences.
> 
Without exposing any internal discussions, it should be obvious to 
anyone "versed in the field" that the ieee754 standard has some warts 
and mistakes. It has been possible to correct very few of them since 1978.

OTOH, Kahan & co did an amazingly good job to start with, the fact that 
they didn't really consider the needs of massively parallel 
implementations 40-50 years later cannot be blamed on them.

It is possible that one or two of the grandfather clauses in 754 can be 
removed in the future, simply because the architectures that made those 
exceptional choices are going away permanently.

I do not see any way to support things like "trap and rescale" as a way 
to handle exponent overruns, even though that was a neat idea back then.

It is much more likely that we will simply switch to quad/f128 (or even 
arbitrary precision) for those few computations that could need it.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#110506

On Tue, 14 Jan 2025 18:39:06 +0000, Terje Mathisen wrote:

> Thomas Koenig wrote:
>> Scott Lurndal <scott@slp53.sl.home> schrieb:
>>
>>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
>>>
>>> Clearly there are programmers who wish to be able to detect
>>> certain exceptions, and POSIX allows programmers to
>>> select that behavior.
>>
>> Clearly, there is a committee which wanted to be able for people
>> to detect certain error conditions on a fine-grained level.
>> One assumes tht they did not consider the consequences.
>>
> Without exposing any internal discussions, it should be obvious to
> anyone "versed in the field" that the ieee754 standard has some warts
> and mistakes. It has been possible to correct very few of them since
> 1978.
>
> OTOH, Kahan & co did an amazingly good job to start with, the fact that
> they didn't really consider the needs of massively parallel
> implementations 40-50 years later cannot be blamed on them.

CDC STAR and CRAY-1 were showing the massive parallelism well before
754 ever sat down.

In addition, the fallacy of exception and repair was also know to be
a failure well before 754 had their first meeting.

> It is possible that one or two of the grandfather clauses in 754 can be
> removed in the future, simply because the architectures that made those
> exceptional choices are going away permanently.
>
> I do not see any way to support things like "trap and rescale" as a way
> to handle exponent overruns, even though that was a neat idea back then.

And just how many EVER used said feature ???

> It is much more likely that we will simply switch to quad/f128 (or even
> arbitrary precision) for those few computations that could need it.
>
> Terje

[toc] | [prev] | [next] | [standalone]

#110508

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> Scott Lurndal <scott@slp53.sl.home> schrieb:
>> 
>>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
>>>
>>> Clearly there are programmers who wish to be able to detect
>>> certain exceptions, and POSIX allows programmers to
>>> select that behavior.
>> 
>> Clearly, there is a committee which wanted to be able for people
>> to detect certain error conditions on a fine-grained level.
>> One assumes tht they did not consider the consequences.
>> 
> Without exposing any internal discussions, it should be obvious to 
> anyone "versed in the field" that the ieee754 standard has some warts 
> and mistakes. It has been possible to correct very few of them since 1978.

I'm not throwing shade on the IEEE committe, they did quite a good
job, considering what they did and did not know.

What I was criticising was the comittee(s) which made errno handling
for functions like sin() and cos() mandatory, and put activating
it in a globel flag.

[toc] | [prev] | [next] | [standalone]

#110512

Thomas Koenig <tkoenig@netcologne.de> writes:
>Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Thomas Koenig wrote:
>>> Scott Lurndal <scott@slp53.sl.home> schrieb:
>>> 
>>>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/sin.html
>>>>
>>>> Clearly there are programmers who wish to be able to detect
>>>> certain exceptions, and POSIX allows programmers to
>>>> select that behavior.
>>> 
>>> Clearly, there is a committee which wanted to be able for people
>>> to detect certain error conditions on a fine-grained level.
>>> One assumes tht they did not consider the consequences.
>>> 
>> Without exposing any internal discussions, it should be obvious to 
>> anyone "versed in the field" that the ieee754 standard has some warts 
>> and mistakes. It has been possible to correct very few of them since 1978.
>
>I'm not throwing shade on the IEEE committe, they did quite a good
>job, considering what they did and did not know.
>
>What I was criticising was the comittee(s) which made errno handling
>for functions like sin() and cos() mandatory, and put activating
>it in a globel flag.

It's not mandatory.   It's listed as an optional extension, and
even when implemented, it's opt-in at compile time.

  "The functionality described is optional. The functionality
   described is mandated by the ISO C standard only for implementations
   that define __STDC_IEC_559__."

[toc] | [prev] | [next] | [standalone]

#110514

scott@slp53.sl.home (Scott Lurndal) writes:
> Thomas Koenig <tkoenig@netcologne.de> writes:
[...]
>>What I was criticising was the comittee(s) which made errno handling
>>for functions like sin() and cos() mandatory, and put activating
>>it in a globel flag.
>
> It's not mandatory.   It's listed as an optional extension, and
> even when implemented, it's opt-in at compile time.
>
>   "The functionality described is optional. The functionality
>    described is mandated by the ISO C standard only for implementations
>    that define __STDC_IEC_559__."

I can't find that anywhere in ISO C or POSIX.  What exactly are you
quoting?  ISO C doesn't tie math_errhandling to __STDC_IEC_559__.

There's no requirement in ISO C or POSIX for an implementation to let
users affect the value of math_errhandling, at compile time or
otherwise.  (And POSIX isn't directly relevant; this is all defined by
ISO C.  There might be something in POSIX that goes beyond the ISO C
requirements.)

gcc has "-f[no-]fast-math" and "-f[no-]math-errno" options that can
affect the value of math_errhandling.

A conforming implementation could set math_errhandling to
(MATH_ERRNO|MATH_ERREXCEPT) and not provide a way to change it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#110517

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>[...]
>>>What I was criticising was the comittee(s) which made errno handling
>>>for functions like sin() and cos() mandatory, and put activating
>>>it in a globel flag.
>>
>> It's not mandatory.   It's listed as an optional extension, and
>> even when implemented, it's opt-in at compile time.
>>
>>   "The functionality described is optional. The functionality
>>    described is mandated by the ISO C standard only for implementations
>>    that define __STDC_IEC_559__."
>
>I can't find that anywhere in ISO C or POSIX.  What exactly are you
>quoting?  ISO C doesn't tie math_errhandling to __STDC_IEC_559__.

https://pubs.opengroup.org/onlinepubs/9799919799/help/codes.html#MX

[toc] | [prev] | [next] | [standalone]

#110520

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>[...]
>>>>What I was criticising was the comittee(s) which made errno handling
>>>>for functions like sin() and cos() mandatory, and put activating
>>>>it in a globel flag.
>>>
>>> It's not mandatory.   It's listed as an optional extension, and
>>> even when implemented, it's opt-in at compile time.
>>>
>>>   "The functionality described is optional. The functionality
>>>    described is mandated by the ISO C standard only for implementations
>>>    that define __STDC_IEC_559__."
>>
>>I can't find that anywhere in ISO C or POSIX.  What exactly are you
>>quoting?  ISO C doesn't tie math_errhandling to __STDC_IEC_559__.
>
> https://pubs.opengroup.org/onlinepubs/9799919799/help/codes.html#MX

OK, but that covers IEC 559 functionality (IEEE floating-point).
The setting (or not) of errno by transcendental functions is
separate from that, and implementations use math_errhandling to
indicate what they do.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#110518

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Thomas Koenig <tkoenig@netcologne.de> writes:

>There's no requirement in ISO C or POSIX for an implementation to let
>users affect the value of math_errhandling, at compile time or
>otherwise.  (And POSIX isn't directly relevant; this is all defined by
>ISO C.  There might be something in POSIX that goes beyond the ISO C
>requirements.)
>
>gcc has "-f[no-]fast-math" and "-f[no-]math-errno" options that can
>affect the value of math_errhandling.

Would not that qualify as at "compile time"?

That's certainly what I meant.

[toc] | [prev] | [next] | [standalone]

#110521

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>>There's no requirement in ISO C or POSIX for an implementation to let
>>users affect the value of math_errhandling, at compile time or
>>otherwise.  (And POSIX isn't directly relevant; this is all defined by
>>ISO C.  There might be something in POSIX that goes beyond the ISO C
>>requirements.)
>>
>>gcc has "-f[no-]fast-math" and "-f[no-]math-errno" options that can
>>affect the value of math_errhandling.
>
> Would not that qualify as at "compile time"?
>
> That's certainly what I meant.

Certainly.  What I wrote is that it's not required by ISO C (or by
POSIX, which as far as I can tell just repeats the ISO C requirements).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#110513

On Tue, 14 Jan 2025 19:39:06 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> 
> It is much more likely that we will simply switch to quad/f128 (or
> even arbitrary precision) for those few computations that could need
> it.
> 
> Terje
> 


I had one of those computations that can benefit from quad and, may be,
from octal precision yesterday/today.
Design of equiripple symmetric FIR filter with ~2000 coefficients (more
commonly called taps) using Parks-McClellan method. Implemented by
Matlab/Octave function that traditionally was called remez and now
called firpm. I suppose, the new name was invented, because the
algorithm is only similar to Remez exchange, but differs in details.

Octave failed to do it claiming of limited precision of arithmetic as a
reason.

In Matlab implementation is better, and it was able to create filter
with ~1800 taps, which happened to be sufficient for my today's needs.
But even Matlab was unable to cope with 2000 taps.

If I had more time, I'd try to implement Parks-McClellan algorithm
myself, to see bottlenecks and see whether higher precision helps a
lot, or just a little. Unfortunately, right now I am too busy with work.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.arch

csiph-web