Re: Calling conventions (particularly 32-bit ARM)

Anton Ertl <anton@mips.complang.tuwien.ac.at> 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.

>
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?
 
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.
I remember issue with writing to strings: early C compilers
put literal strings in writable memory and programs assumed that
they can change strings.  C 'errno' was made more abstract due
to multithreading, it broke some programs.  Concerning varags,
Power PC and later AMD-64 used calling convention incompatible
with popular expectations.

Concerning customers, they will tolerate a lot of things, as long
as there are benefits (faster or cheaper machines, better security,
etc.) and fixes require reasonable amount of work.  So that
really is question of cost/benefit ratio.

--
                              Waldek Hebisch