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: References: <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 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