Re: Calling conventions (particularly 32-bit ARM)

Liste des GroupesRevenir à c arch 
Sujet : Re: Calling conventions (particularly 32-bit ARM)
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.arch
Date : 14. Jan 2025, 19:02:29
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2025Jan14.190229@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : xrn 10.11
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>

Date Sujet#  Auteur
13 Jan 25 * Re: Calling conventions (particularly 32-bit ARM)25Thomas Koenig
13 Jan 25 `* Re: Calling conventions (particularly 32-bit ARM)24MitchAlsup1
13 Jan 25  +* Re: Calling conventions (particularly 32-bit ARM)22MitchAlsup1
14 Jan 25  i+* Re: Calling conventions (particularly 32-bit ARM)17MitchAlsup1
14 Jan 25  ii+- Re: Calling conventions (particularly 32-bit ARM)1David Brown
14 Jan 25  ii+* Re: Calling conventions (particularly 32-bit ARM)2Michael S
14 Jan 25  iii`- Re: Calling conventions (particularly 32-bit ARM)1Anton Ertl
14 Jan 25  ii+- Re: Calling conventions (particularly 32-bit ARM)1MitchAlsup1
14 Jan 25  ii`* Re: Calling conventions (particularly 32-bit ARM)12Thomas Koenig
14 Jan 25  ii +* Re: Calling conventions (particularly 32-bit ARM)7Terje Mathisen
14 Jan 25  ii i+- Re: Calling conventions (particularly 32-bit ARM)1MitchAlsup1
14 Jan 25  ii i+* Re: Calling conventions (particularly 32-bit ARM)4Thomas Koenig
15 Jan 25  ii ii`* Re: Calling conventions (particularly 32-bit ARM)3Keith Thompson
15 Jan 25  ii ii +- Re: Calling conventions (particularly 32-bit ARM)1Keith Thompson
15 Jan 25  ii ii `- Re: Calling conventions (particularly 32-bit ARM)1Keith Thompson
14 Jan 25  ii i`- Re: Calling conventions (particularly 32-bit ARM)1Michael S
14 Jan 25  ii +- Re: Calling conventions (particularly 32-bit ARM)1MitchAlsup1
14 Jan 25  ii `* Re: Calling conventions (particularly 32-bit ARM)3Thomas Koenig
14 Jan 25  ii  `* Re: Calling conventions (particularly 32-bit ARM)2Michael S
15 Jan 25  ii   `- Re: Calling conventions (particularly 32-bit ARM)1MitchAlsup1
14 Jan 25  i+- Re: Calling conventions (particularly 32-bit ARM)1Thomas Koenig
14 Jan 25  i`* Re: Calling conventions (particularly 32-bit ARM)3David Brown
14 Jan 25  i `* Re: Calling conventions (particularly 32-bit ARM)2David Brown
15 Jan 25  i  `- Re: Calling conventions (particularly 32-bit ARM)1Keith Thompson
14 Jan 25  `- Re: Calling conventions (particularly 32-bit ARM)1Keith Thompson

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal