Path: ...!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.arch
Subject: Re: Calling conventions (particularly 32-bit ARM)
Date: Tue, 7 Jan 2025 02:11:45 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vli2gu$1aftg$1@paganini.bofh.team>
References: <vlgngv$1ks4a$1@dont-email.me> <4903307dfcce354508c9fc016a4c1ea1@www.novabbs.org>
Injection-Date: Tue, 7 Jan 2025 02:11:45 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="1392560"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 3028
Lines: 45

MitchAlsup1 <mitchalsup@aol.com> wrote:
>> 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.
> 
> Basically, here, there is competing pressure between the compiler
> needing a handful of preserved registers, and the compiler being
> more efficient if there were more argument/result passing registers.
> 
> My 66000 ABI has 8 argument registers, 7 temporary registers, 14
> preserved registers, a FP, and a SP. IP is not part of the register
> file. My ABI has a note indicating that the aggregations can be
> altered, just that I need a good reason to change.
> 
> I looked high and low for codes using more than 8 arguments and
> returning aggregates larger than 8 double words, and about the
> only things I found were a handful of []print[]() calls.

I meet such code with reasonable frequency.  I peeked semi
randomly into Lapack.  First routine that I looked at had
8 arguments, so within your limit.  Second is:

      SUBROUTINE ZUNMR3( SIDE, TRANS, M, N, K, L, A, LDA, TAU, C, LDC,
     $                   WORK, INFO )

which has 13 arguments.

Large number of arguments is typical in old style Fortran numeric
code.  It also appears in functional-style code, where to get
around lack of destructive modification one freqenty have to
double number of arguments.  Another source is closures: when
looking at source captured values are not visible as arguments,
but implementation has to pass them behind the scenes.

More generally, large number of arguments tend to appear in
hand-optimized where they may lead to faster code than
using structures in memory.  In C structures in memory are
not that expensive, so scope for gain is limited, but several
languages dynamically allocate all structures (and pass then
via address).  In such case avoiding dynamic allocation can
give substantial gain.  Programmers now are much less
inclined to do microptimizations of this sort.  But it may
appear in machine generated sources.

-- 
                              Waldek Hebisch