Re: Calling conventions (particularly 32-bit ARM)

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.