Re: Calling conventions (particularly 32-bit ARM)

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.