Re: Calling conventions (particularly 32-bit ARM)

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.