Re: Calling conventions (particularly 32-bit ARM)

On Fri, 10 Jan 2025 10:25:23 +0000, Anton Ertl wrote:

antispam@fricas.org (Waldek Hebisch) writes:

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

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.
A lot of VAX programs needed fixes to run on different machines.

>
That case is interesting.  It's certainly a benefit to programmers if
most uses of NULL produce a SIGSEGV, but for existing programs mapping
allowing to have accessible memory in page 0 is an advantage.  So how
did we get from there to where we are now?

The blame goes to defining NULL as a pointer that is not pointing at
anything. We have no integer that has the property of one value that
is not an integer--we COULD have had such a value (NEG_MAX on 2's
complement, -0 on 1's complement), but no..........

C 'errno' was made more abstract due
to multithreading, it broke some programs.

errno is an atrocity all by itself; single handedly preventing
direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
as instructions.
Lobbing errno over into Thread Local Store just makes the problems
worse.

That's pretty similar to an ABI issue (not sure if errno is in the
ABIs or not).

errno is not ABI, errno is part of subroutine definitions within
a library. That errno can be set from different libraries, and
that errno got dropped in TLS makes it doubly idiotic.