Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Calling conventions (particularly 32-bit ARM)
Date: Sun, 12 Jan 2025 12:10:50 -0800
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <vm17ka$1d58r$1@dont-email.me>
References: <vlgngv$1ks4a$1@dont-email.me>
 <4903307dfcce354508c9fc016a4c1ea1@www.novabbs.org>
 <vli2gu$1aftg$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 12 Jan 2025 21:10:51 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fb23e6b923e5c71a5ffe27ccce377dc3";
	logging-data="1479963"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19rQGBmgTHM/2285aBUkXNWBTKpM/XExWw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:CeeNNQsEYCR5NCSFfc8SH90sqsg=
Content-Language: en-US
In-Reply-To: <vli2gu$1aftg$1@paganini.bofh.team>
Bytes: 3054

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)