Re: Calling conventions (particularly 32-bit ARM)

On 1/6/2025 6:11 PM, Waldek Hebisch wrote:

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.

While there has been much discussion down thread relating to Waldek's other points, there hasn't been much about these.
So, some questions.  Has Lapack (and the other old style Fortran numeric code that Waldek mentioned) lost its/their importance as a major user of CPU cycles?  Or do these subroutines consume so many CPU cycles that the overhead of the large number of parameters is lost in the noise? Or is there some other explanation for Mitch not considering their importance?
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)