Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Calling conventions (particularly 32-bit ARM) Date: Fri, 10 Jan 2025 01:08:16 +0000 Organization: Rocksolid Light Message-ID: References: <4903307dfcce354508c9fc016a4c1ea1@www.novabbs.org> <2025Jan8.230846@mips.complang.tuwien.ac.at> <2025Jan9.082357@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="2857916"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$9TSSOGi6aXx8IU1Qgfcgn.LEfOdHIwzxB6IwvpkB2HuKgqI.O54cy X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 3521 Lines: 65 On Thu, 9 Jan 2025 21:23:30 +0000, Thomas Koenig wrote: > MitchAlsup1 schrieb: >> On Thu, 9 Jan 2025 7:23:57 +0000, Anton Ertl wrote: >> >>> Stefan Monnier 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? >> >> No, I would stand my ground and mandate that they do work. > > That can be tricky. You can read > > https://blog.r-project.org/2019/05/15/gfortran-issues-with-lapack/index.html > > and its sequel > > https://blog.r-project.org/2019/09/25/gfortran-issues-with-lapack-ii/ > > as a cautionary tale. Yes, I had to make a nasty ABI work on the HEP (Denelcor) > To cut this a little shorter: Assume eight arguments are passed in > registers, like for My 66000. > > Caller calls > > foo (a1, a2, a3, a4, a5, a6, a7, a8); > > Callee side: > > foo (a1, a2, a3, a4, a5, a6, a7, a8, a9) > > Foo ends with > > bar (b1, b2, b3, b4, b5, b6, b7, b8, b9); > > and wants to save stack space, so it stores the value of b9 into > the space where it was supposed to be, and then branches to bar. > Result: Stack corruption. > > What would you tell your ABI designer in that case? Don't do tail > calls, it is better to use more stack space, with all effect on > stack sizes and locality that would have? Same response I would give to:: printf( "%d %d %d %d %d/r", a[i] ); "They deserve what they get". You will notice that no ISA has ever had a "go jump in the lake" instruction. For had there been, computers would not have survived the the present--they would all be in the lake...