Re: Calling conventions (particularly 32-bit ARM)

On Mon, 6 Jan 2025 15:32:04 +0000, Anton Ertl wrote:

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

But the ABI only allows returning a single 32-bit value in R0, or a
scalar 64-bit value in R0:R1.  If a function returns a non-scalar that
is larger than 32-bit, the caller has to allocate space on the stack for
the return type and pass a pointer to that space in R0.
>
To my mind, this is massively inefficient, especially when using structs
that are made up of two 32-bit parts.
>
Is there any good reason why the ABI is designed with such limited
register usage for returns?

>
Most calling conventions on RISCs are oriented towards C (if you want
calling conventions that try to be more cross-language (and slower),
look at VAX) and its properties and limitations at the time when the
calling convention was designed, in particular, the PCC
implementation, which was the de-facto standard Unix C compiler at the
time.  C compilers in the 1980s did not allocate structs to registers,
so passing structs in registers was foreign to them, so the solution
is that the caller passes the target struct as an additional
parameter.
>
And passing the return value in registers might not have saved
anything on a compiler that does not deal with structs in registers.
E.g., if you have
>
mystruct = myfunc(arg1, arg2);
>
you would see stores to mystruct behind the call.  With the PCC
calling convention, the same stores would happen in the caller
(possibly resulting in smaller code if there are several calls to
myfunc()).
>
I wonder, though, how things look for
>
mystruct = foo(&mystruct);
>
Does PCC perform the return stores to mystruct only after performing
all other memory accesses in foo?  Probably yes, anything else would
complicate the compiler.  In that case the caller could pass &mystruct
for the return value (a slight complication).  But is that restriction
reflected in the calling convention?

For VERY MANY circumstances passing a struct by address is more
efficient than passing it by value, AND especially when the
compiler does not optimize heavily.

Struct returns were (and AFAIK still are, many decades after
they were added to C) a relatively rarely used feature, so Johnson
(PCC's author) probably did not want to waste a lot of effort on
making it more efficient.

In addition, the programmer has the choice of changing into pointer
form (&struct) from value form (struct) which is what we learned
was better style way back then.
--------------------------

I also think code would be a bit more efficient if there more registers
available for parameter passing and as scratch registers - perhaps 6
would make more sense.

>
There is a tendency towards passing more parameters in registers in
more recent calling conventions.  IA-32 (and IIRC VAX) passes none,
MIPS uses 4 integer registers (for either integer or FP parameters),
Alpha uses 6 integer and 6 FP registers, AMD64's System V ABI 6
integer and 8 FP registers, ARM A64 has 8 integer and 8 FP registers,
RISC-V has 8 integer and 8 FP registers.  Not sure why they were so
reluctant to use more registers earlier.

Compiler people were telling us that more callee saved registers would
be higher performing than more argument registers. It did not turn out
to be that way.
Oh and BTW, lack of argument registers leads to an increased
desire for the linker to perform inline folding. ...

>
- anton