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 5 of 5 — ← Prev page 1 2 3 4 [5]

#110505

On Tue, 14 Jan 2025 18:19:12 +0000, 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.

When the numeric calculation of sin() takes 150 cycles, the over-
head matters little.

When the numeric calculation of sin() takes 15 cycles, the over-
head is more noticeable.

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

#110507

Thomas Koenig <tkoenig@netcologne.de> writes:
>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.

I spent several years on one of those committees[*] in the 90s.  There were math and IEEE
FP experts who very carefully considered all the consequences of changes
to the math interfaces.

[*] X/Open -> The Open Group

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

#110509

Scott Lurndal <scott@slp53.sl.home> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>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.
>
> I spent several years on one of those committees[*] in the 90s.  There were math and IEEE
> FP experts who very carefully considered all the consequences of changes
> to the math interfaces.

Putting in mandatory errno handling for transcencental intrinsics,
and making this dependent on a global flag, was a huge mistake.

Either the people on that particular committee didn't consider
the consequences, or they (second option to the one above) didn't
understand the consequences what they were doing.  Vector computers
had already been in service for a decade when POSIX was released,
and a question "Would it run well on a Cray" would have answered
itself.

OTOH, they can be excused if they thought that C should not be
be used for serious numerical work, and would not be.  People had
FORTRAN for that...

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

#110510

On Tue, 14 Jan 2025 20:31:59 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Scott Lurndal <scott@slp53.sl.home> schrieb:
> > Thomas Koenig <tkoenig@netcologne.de> writes:  
> >>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.  
> >
> > I spent several years on one of those committees[*] in the 90s.
> > There were math and IEEE FP experts who very carefully considered
> > all the consequences of changes to the math interfaces.  
> 
> Putting in mandatory errno handling for transcencental intrinsics,
> and making this dependent on a global flag, was a huge mistake.
> 

Except that they didn't do this particular mistake.
Please, read other messages of the sub-thread.

> Either the people on that particular committee didn't consider
> the consequences, or they (second option to the one above) didn't
> understand the consequences what they were doing.  Vector computers
> had already been in service for a decade when POSIX was released,
> and a question "Would it run well on a Cray" would have answered
> itself.
>

Cray-1 still was small enough for errno-based handling of errors in
trigs to not be a serious obstacle. That is, not Cray-1 itself, but
imaginary machine with organization, similar to Cray, but with more
consistent FP arithmetic.

> OTOH, they can be excused if they thought that C should not be
> be used for serious numerical work, and would not be.  People had
> FORTRAN for that...

I would guess that today majority of numerical work is done from python
by calling libraries. Libraries tend to be written in highly
none-portable dialects of C language and sometimes in C++. I don't
expect that measurable amount of Fortran is used in creation of the
libraries.
Now, whether one consideres overwhelming majority of today's numerical
work "serious" is a separate question. But it certainly is a very
serious business.

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

#110519

On Tue, 14 Jan 2025 21:13:40 +0000, Michael S wrote:

>
> I would guess that today majority of numerical work is done from python
> by calling libraries.

New software, but many of us are still using FEM from 1970s.

That is the problem with floating point software--once developed
you can continue using it forever.

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

#110489

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

> 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.

That makes SIMD-style vectorization of transcendentals...
interesting.

Hmmm... looking around, it seems that C++ has the same requirement
since C++11.  One more reason why Fortran is a better language
for numerics than C++...

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

#110492

On 13/01/2025 23:40, 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.
> 

You know POSIX better than I do, but AFAIK "math_errhandling" is a fixed 
value set by the implementation, usually as a macro.  Certainly with a 
quick check with gcc on Linux, I could not set the bits in math_errhandling.

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

#110495

David Brown <david.brown@hesbynett.no> writes:
>On 13/01/2025 23:40, 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.
>> 
>
>You know POSIX better than I do, but AFAIK "math_errhandling" is a fixed 
>value set by the implementation, usually as a macro.  Certainly with a 
>quick check with gcc on Linux, I could not set the bits in math_errhandling.
>

Yes, the programmer in this case would instruct the compiler what
the value of math_errhandling should be, e.g. with --ffast-math.

https://gcc.gnu.org/wiki/FloatingPointMath

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

#110497

On 14/01/2025 15:39, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 13/01/2025 23:40, 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.
>>>
>>
>> You know POSIX better than I do, but AFAIK "math_errhandling" is a fixed
>> value set by the implementation, usually as a macro.  Certainly with a
>> quick check with gcc on Linux, I could not set the bits in math_errhandling.
>>
> 
> Yes, the programmer in this case would instruct the compiler what
> the value of math_errhandling should be, e.g. with --ffast-math.
> 
> https://gcc.gnu.org/wiki/FloatingPointMath

I would say the key flag here is "-fno-math-errno" (which is included in 
-ffast-math).  While I personally think most floating point code could 
be used just as well with "-ffast-math", and it is certainly appropriate 
for my own code, others have significantly different opinions or 
experiences.  (That's fair enough.)  That one flag simply disables 
setting errno in maths functions that can (reasonably) be implemented 
inline as instructions, without affecting the results of any other 
floating point operations.

But to my mind, this is /not/ a case of the POSIX programmer making the 
choice - it is an implementation-specific feature.  A C compiler might 
choose to always use errno, or never, or have some other control of the 
use of errno.  When you write "POSIX leaves it up to the programmer", I 
take that to mean POSIX specifies a function that lets you change the 
value of "math_errhandling".  That is quite different from saying "gcc 
has a flag that lets you choose".

(For my own use, I like the flag - I don't write POSIX code, I have 
never had any use for errno, and I want the compiler to generate as few 
instructions as it possibly can.)

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

#110516

David Brown <david.brown@hesbynett.no> writes:
[...]
> I would say the key flag here is "-fno-math-errno" (which is included
> in -ffast-math).  While I personally think most floating point code
> could be used just as well with "-ffast-math", and it is certainly
> appropriate for my own code, others have significantly different
> opinions or experiences.  (That's fair enough.)  That one flag simply
> disables setting errno in maths functions that can (reasonably) be
> implemented inline as instructions, without affecting the results of
> any other floating point operations.
>
> But to my mind, this is /not/ a case of the POSIX programmer making
> the choice - it is an implementation-specific feature.  A C compiler
> might choose to always use errno, or never, or have some other control
> of the use of errno.  When you write "POSIX leaves it up to the
> programmer", I take that to mean POSIX specifies a function that lets
> you change the value of "math_errhandling".  That is quite different
> from saying "gcc has a flag that lets you choose".

math_errhandling is specified by ISO C, starting with C99.  POSIX merely
copies and refers to the ISO C requirements.  (POSIX might add some
requirements, but I haven't seen that.)  I suggest that POSIX is
irrelevant to this discussion.

As far as I can tell, there is no POSIX (or ISO C) function that changes
the value of math_errhandling.  In fact, such a function would violate
the ISO C rule that "The value of math_errhandling is constant for the
duration of the program.".

> (For my own use, I like the flag - I don't write POSIX code, I have
> never had any use for errno, and I want the compiler to generate as
> few instructions as it possibly can.)

-- 
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]

#110491

scott@slp53.sl.home (Scott Lurndal) writes:
> 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'.

math_errhandling is specified by ISO C, starting with the 1999 edition
of the standard.

The value of math_errhandling is determined by the implementation, not
by the application.  "The value of math_errhandling is constant for the
duration of the program."  (A compiler could provide an option to set
the value; I don't know whether any do so.)

https://www.iso-9899.info/n1570.html#7.12

-- 
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]

#110463

antispam@fricas.org (Waldek Hebisch) writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> [Someone wrote:]
>>>> ABI calling conventions tend to be designed to support at least C,
>>>> including varargs and often also tolerant of differences between the
>>>> number of arguments in the caller and callee.
>>>
>>>I can agree that it's important to support those use-cases (varargs
>>>obviously, mismatched arg numbers less so),
>> 
>> You are head of a group of people who design a new architecture (say,
>> it's 2010 and you design ARM A64, or it's 2014 and you design RISC-V).
>> Your ABI designer comes to you and tells you that his life would be
>> easier if it was ok that programs with mismatched arguments don't need
>> to work.  Would you tell him that they don't need to work?
>> 
>> If yes, a few years down the road your prospective customers have to
>> decide whether to go for your newfangled architecture or one of the
>> established ones.  They learn that a number of programs work
>> everywhere else, but not on your architecture.  How many of them will
>> be placated by your reasoning that these programs are not strictly
>> confoming standard programs?  How many will be alarmed by your
>> admission that you find it ok that you find it ok that such programs
>> don't work on your architecture?  After all, hardly any program is a
>> strictly conforming standard program.
>
>Such things happended many times in the past.  AFAIK standard
>setup on a VAX was that accessing data at address 0 gave you 0.

That was a BSD thing.   USL spent a fair bit of time fixing
BSD utilities that relied on the BSD behaviour when porting
to System V release 4.

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

#110465

On 09/01/2025 08:23, Anton Ertl wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> [Someone wrote:]
>>> ABI calling conventions tend to be designed to support at least C,
>>> including varargs and often also tolerant of differences between the
>>> number of arguments in the caller and callee.

Why should an ABI be tolerant of such differences?  In C, calling a 
function with an unexpected number (or type) of arguments has always 
been undefined behaviour, and always been something that programmers 
have strived to avoid.  For variadic functions (including old 
pre-standard functions), the code does not declare the number or types 
of arguments, but you still have to match up the caller and callee. 
Call printf() with a mismatch between the format string and the 
arguments, and you can expect nasal daemons.

I am all in favour of things like ABI's not intentionally making things 
significantly worse - no one wants a system that turns code bugs into 
something like an exploitable security hole from stack corruption.

However, I see no good reason to try to make things "work" with broken 
code.  An ABI should be designed with an emphasis on being efficient for 
correct code - not for being tolerant of hopelessly incorrect code.

C /does/ require support for variadic functions, so that has to be in 
any ABI usable with C.

>>
>> I can agree that it's important to support those use-cases (varargs
>> obviously, mismatched arg numbers less so),
> 
> You are head of a group of people who design a new architecture (say,
> it's 2010 and you design ARM A64, or it's 2014 and you design RISC-V).
> Your ABI designer comes to you and tells you that his life would be
> easier if it was ok that programs with mismatched arguments don't need
> to work.  Would you tell him that they don't need to work?
> 

I would, yes.  The efficiency of good code should not suffer because of 
the existence of bad code.

I'd still try to avoid making results that are more dangerous than 
necessary.  Maybe you do that by making it clear to compiler writers 
that the ABI should not be used with a compiler that supports implicit 
function declarations - that would block most risky or broken code at 
compile time.  Perhaps you say that object files using this ABI need 
extra sections holding basic information about the function's parameters 
with its definition, and about the arguments when calling the function, 
and encouraging linkers to check for mismatches.  There would surely be 
cases where you can't check - casts of function pointer types, dynamic 
linking, etc., - but you would again eliminate a large proportion of errors.

> If yes, a few years down the road your prospective customers have to
> decide whether to go for your newfangled architecture or one of the
> established ones.  They learn that a number of programs work
> everywhere else, but not on your architecture.  How many of them will
> be placated by your reasoning that these programs are not strictly
> confoming standard programs?  How many will be alarmed by your
> admission that you find it ok that you find it ok that such programs
> don't work on your architecture?  After all, hardly any program is a
> strictly conforming standard program.

How many people actually want to use code where some functions are 
called with an incorrect number of parameters?  Such code is /broken/. 
If it ever gave results that the original users were happy with, it is 
by luck - no matter what ABI you have for your new architecture and new 
tools, it's pure luck whether things work or not in any sense.

So the best you can do for your prospective customers is tell them that 
you prioritise the results for correct code and help them with tools to 
find mistakes in their ancient broken code.

Accepting the unfortunate reality that most code of a significant size 
has /some/ bugs in it does not mean it is a good idea to reduce the 
efficiency of good code in a vain attempt at replicating the luck of old 
undefined behaviour on other platforms!  That is especially true for a 
class of error that only exists due to very sloppy development 
practices, and should be identifiable by automatic linting and static 
checking.

It never ceases to disappoint me how lax C is at fixing things that were 
design flaws from day one of the language.  Backwards compatibility is 
very important, but allowing such crappy coding to be accepted simply 
encourages more people to write crappy code for longer.  C compilers are 
even worse, as they usually support crappy code for longer than the C 
standards.  Implicit function declarations were removed from the C 
language in C99, and non-prototype declarations were made obsolescent in 
C90, yet not removed from the language until C23.

> 
>> only sloppy ancient C calls
>> functions without proper declarations)
> 
> You find it ok to design a calling convention such that ancient C
> programs do not work?
> 

My original post was about an ABI for microcontroller programming.  For 
that use, my answer is a definite "yes".

For more general use, my answer would also be "yes" for a new 
architecture and ABI.  I don't see why anyone should pander to ancient 
sloppy code.  If there really is a significant body of C code that does 
not use function prototypes, and that code really is still useful and 
relevant, then it should not be much of a challenge to write a little 
utility program that converts the old code to something more modern. 
Maybe clang-format can already do that.

> What benefit do you expect from such a calling convention?  To allow
> to use registers as arguments (and not callee-saved) that would
> otherwise be preferably used as callee-saved registers?
> 

That sounds like a benefit to me.

> 
>> even if it comes at the cost of
>> using different calling conventions for the two cases.
> 
> That would mean that you find it ok that existing programs that use
> vararg functions like printf but do not declare them before use don't
> work on your newfangled architecture.

I would certainly be OK with that.  I can understand that some people 
will disagree, but I really think there are better ways to handle old 
and/or broken code.

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

#110466

David Brown <david.brown@hesbynett.no> writes:
>On 09/01/2025 08:23, Anton Ertl wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> [Someone wrote:]
>>>> ABI calling conventions tend to be designed to support at least C,
>>>> including varargs and often also tolerant of differences between the
>>>> number of arguments in the caller and callee.
>
>Why should an ABI be tolerant of such differences?  In C, calling a 
>function with an unexpected number (or type) of arguments has always 
>been undefined behaviour, and always been something that programmers 
>have strived to avoid.  For variadic functions (including old 
>pre-standard functions), the code does not declare the number or types 
>of arguments, but you still have to match up the caller and callee. 

I'm not sure that's completely true.   Consider, for example,
main().  It's sort of variadic, but most applications only declare
the standard C argc/argv arguments.  POSIX systems supply
a third parameter (envp) and most unix/linux implementations
supply a fourth parameter (auxv).

I should think so long as the caller provides at least enough
parameters to match the callee, there shouldn't be any
issues.

>Call printf() with a mismatch between the format string and the 
>arguments, and you can expect nasal daemons.

Not if you provide _more_ parameters than the format string
requires, which can happen with e.g. i18n error message strings.

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

#110472

On 10/01/2025 19:39, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/01/2025 08:23, Anton Ertl wrote:
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> [Someone wrote:]
>>>>> ABI calling conventions tend to be designed to support at least C,
>>>>> including varargs and often also tolerant of differences between the
>>>>> number of arguments in the caller and callee.
>>
>> Why should an ABI be tolerant of such differences?  In C, calling a
>> function with an unexpected number (or type) of arguments has always
>> been undefined behaviour, and always been something that programmers
>> have strived to avoid.  For variadic functions (including old
>> pre-standard functions), the code does not declare the number or types
>> of arguments, but you still have to match up the caller and callee.
> 
> I'm not sure that's completely true.   Consider, for example,
> main().  It's sort of variadic, but most applications only declare
> the standard C argc/argv arguments.  POSIX systems supply
> a third parameter (envp) and most unix/linux implementations
> supply a fourth parameter (auxv).
> 
> I should think so long as the caller provides at least enough
> parameters to match the callee, there shouldn't be any
> issues.

main() is a special case in C and C++ - it seems fine to say that it 
takes a particular implementation-defined set of parameters no matter 
how it is declared.  If it is defined with fewer parameters than the 
implementation supports, then the definition should be treated as though 
those parameters were included but not used.

> 
>> Call printf() with a mismatch between the format string and the
>> arguments, and you can expect nasal daemons.
> 
> Not if you provide _more_ parameters than the format string
> requires, which can happen with e.g. i18n error message strings.
> 

I've always thought printf was a very unsafe design concept - that usage 
does not help!

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

#110467

David Brown <david.brown@hesbynett.no> schrieb:

> How many people actually want to use code where some functions are 
> called with an incorrect number of parameters?  Such code is /broken/. 

Agreed (at least in priciple).

> If it ever gave results that the original users were happy with, it is 
> by luck - no matter what ABI you have for your new architecture and new 
> tools, it's pure luck whether things work or not in any sense.

It gets worse when the code in question has been around for decades,
and is widely used.  Some ABIs, such as the x86-64 psABI, are very
forgiving of errors.

> So the best you can do for your prospective customers is tell them that 
> you prioritise the results for correct code and help them with tools to 
> find mistakes in their ancient broken code.

Now, you can also tell them to use LTO for checks for any old
software.

Example:

$ cat main.c 
#include <stdio.h>

int foo(int);

int main()
{
  printf ("%d\n", foo(42));
}
$ cat foo.c 
int foo (int a, int b)
{
  return a + 2;
}
$ gcc -O2 -flto main.c foo.c 
main.c:3:5: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
    3 | int foo(int);
      |     ^
foo.c:1:5: note: type mismatch in parameter 2
    1 | int foo (int a, int b)
      |     ^
foo.c:1:5: note: type 'int' should match type 'void'
foo.c:1:5: note: 'foo' was previously declared here

This also works when the declaration is hidden (for example when
the violating code is emitted by a compiler for another language
in the same compiler collection):

$ cat main.f90 
program main
  implicit none
  interface
     function foo(a) result(ret) bind(c)
       use, intrinsic :: iso_c_binding, only: c_int
       integer(c_int), value :: a
       integer(c_int) :: ret
     end function foo
  end interface
  print *,foo(42)
end program main
$ gfortran -O2 -flto main.f90 foo.c 
main.f90:10:17: warning: type of 'foo' does not match original declaration [-Wlto-type-mismatch]
   10 |   print *,foo(42)
      |                 ^
foo.c:1:5: note: type mismatch in parameter 2
    1 | int foo (int a, int b)
      |     ^
foo.c:1:5: note: type 'int' should match type 'void'
foo.c:1:5: note: 'foo' was previously declared here

Excuses are running out.

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

#110473

On 10/01/2025 20:19, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
> 
>> How many people actually want to use code where some functions are
>> called with an incorrect number of parameters?  Such code is /broken/.
> 
> Agreed (at least in priciple).
> 
>> If it ever gave results that the original users were happy with, it is
>> by luck - no matter what ABI you have for your new architecture and new
>> tools, it's pure luck whether things work or not in any sense.
> 
> It gets worse when the code in question has been around for decades,
> and is widely used.  Some ABIs, such as the x86-64 psABI, are very
> forgiving of errors.
> 
>> So the best you can do for your prospective customers is tell them that
>> you prioritise the results for correct code and help them with tools to
>> find mistakes in their ancient broken code.
> 
> Now, you can also tell them to use LTO for checks for any old
> software.
> 
> 
> Excuses are running out.

Yes, exactly.

I saw somewhere a quotation that backwards compatibility just means 
repeating the same old mistakes.  Backwards compatibility /is/ 
important, but so is trying to improve coding practices!

[toc] | [prev] | [standalone]

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

Back to top | Article view | comp.arch

csiph-web