Re: Calling conventions (particularly 32-bit ARM)

On 06/01/2025 16:23, Theo wrote:

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

The big problem I see is the registers used for returning values from
functions.  R0-R3 can all be used for passing arguments to functions, as
32-bit (or smaller) values, pointers, in pairs as 64-bit values, and as
parts of structs.
>
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.

 According to EABI, it's also possible to return a 128 bit vector in R0-3:
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#result-return
 

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?  Newer ABIs like RISC-V 32-bit and x86_64
can at least use two registers for return values.  Modern compilers are
quite happy breaking structs into parts in individual registers - it's a
/long/ time since they insisted that structs occupied a contiguous block
of memory.  Can anyone give me an explanation why return types can't
simply use all the same registers that are available for argument passing?

 The 'composite type' return value, where a pointer is passed in as the first
argument to the function and a struct at that pointer is filled in with the
return values, has existed since the first ARM ABI - APCS-R:
http://www.riscos.com/support/developers/dde/appf.html
 That dates from the mid 1980s before 'modern compilers', and I'm guessing
that has stuck around.  A lot of early ARM code was in assembler.  The
original ARMCC was good but fairly basic - GCC didn't support ARM until
about 1993.
 [*] technically APCS-R was the second ARM ABI, APCS-A was the first:
https://heyrick.eu/assembler/apcsintro.html
but I don't think return value handling was any different.
 

Are there good technical reasons for the conventions on 32-bit ARM?  Or
is this all just historical from the days when everything was an "int"
and that's all anyone ever returned from functions?

 Probably the latter.

It certainly seems that way to me.  But there was always the possibility that there were technical reasons that I had not thought of.

Also that AArch64 was an opportunity to throw all this
stuff away and start again, with a much richer calling convention:
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#result-return
 but obviously that's no help to the microcontroller folks.  At this stage, a
change of calling convention might be fairly big ask.
 

Actually, I disagree on that one.  In the microcontroller world, changing calling conventions should not be nearly as difficult as it would be on hosted systems because you are rarely dealing with pre-compiled object code.  And there are already many variations on calling conventions for 32-bit ARM devices - for thumb or ARM code, and for all the different combinations of floating point registers which may or may not be used.
The pre-compiled object code you always have is basic C libraries and compiler support libraries (things like software floating point routines).  For a typical 32-bit embedded gcc ARM toolchain there are already 30+ builds for libraries for all the different variants of the architecture and calling conventions - a few more won't be a problem.
Then there are some RTOS's and other commercial libraries that are only available in binary form.  Most of these are written in crappy ancient C90 - they won't return structs or other bigger data anyway, and thus be unaffected by such changes.  And it would not be difficult for these suppliers to re-compile with new options either.