Re: Calling conventions (particularly 32-bit ARM)

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.arch
Subject	Re: Calling conventions (particularly 32-bit ARM)
Date	2026-03-14 09:34 -0700
Organization	A noiseless patient Spider
Message-ID	<86a4wa74k0.fsf@linuxsc.com> (permalink)
References	(2 earlier) <ve4rnjpipquiugm3j1831m0a7v0va4lu03@4ax.com> <86lduv3frs.fsf@linuxsc.com> <uh8jpj1qarqbauqdv3lk4foikocgbv7fq9@4ax.com> <86o6lqhb5x.fsf@linuxsc.com> <tqf9pk9kfchiaib67sfgchjm84sspnl5oe@4ax.com>

Show all headers | View raw

George Neuner <gneuner2@comcast.net> writes:

> Hi Tim,

Hi. :)

> On Sat, 14 Feb 2026 20:40:26 -0800, Tim Rentsch
> <tr.17687@z991.linuxsc.com> wrote:
>
>> George Neuner <gneuner2@comcast.net> writes:
>>
>>> On Mon, 27 Jan 2025 17:09:59 -0800, Tim Rentsch
>>> <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> George Neuner <gneuner2@comcast.net> writes:
>>>>
>>>>> On Mon, 6 Jan 2025 20:10:13 +0000, mitchalsup@aol.com (MitchAlsup1)
>>>>> wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Large numbers of parameters may be generated either by closure
>>>>> conversion or by lambda lifting.  These are FP language
>>>>> transformations that are analogous to, but potentially more complex
>>>>> than, the rewriting of object methods and their call sites to pass the
>>>>> current object in an OO language.
>>>>>
>>>>> [The difference between closure conversion and lambda lifting is the
>>>>> scope of the tranformation:  conversion limits code transformations to
>>>>> within the defining call chain, whereas lifting pulls the closure to
>>>>> top level making it (at least potentially) globally available.]
>>>>>
>>>>> In either case the original function is rewritten such that non-local
>>>>> variables can be passed as parameters.  The function's code must be
>>>>> altered to access the non-locals - either directly as explicit
>>>>> individual parameters, or by indexing from a pointer to an environment
>>>>> data structure.
>>>>>
>>>>> While in a simple case this could look exactly like the OO method
>>>>> transformation, recall that a general closure may require access to
>>>>> non-local variables spread through multiple environments.  Even if
>>>>> whole environments are passed via single pointers, there still may
>>>>> need to be multiple parameters added.
>>>>
>>>> Isn't it the case that access to all of the enclosing environments
>>>> can be provided by passing a single pointer?  I'm pretty sure it
>>>> is.
>>>
>>> Certainly, if the enclosing environments somehow are chained together.
>>> In real code though, in many instances such a chain will not already
>>> exist when the closure is constructed.  The compiler would have to
>>> install pointers to the needed environments (or, alternatively,
>>> pointers directly to the needed values) into the new closure's
>>> immediate environment.
>>> [essentially this creates a private "display" for the closure.]
>>>
>>> Completely doable:  it is simply that, if there are enough registers,
>>> passing the pointers as parameters will tend to be more performant.
>>
>> Sounds like you're saying that you agree that passing
>> just one value is always feasible.  Also that, depending
>> on individual circumstances, either approach might have
>> better performance.
>
> You are correct ... it always is possible to pass the closure
> environment to the function using a single pointer.
>
> But you may not want to do it that way.
>
>
> My point was about the structure of closure environments.  In general,
> you want to minimize what data needs to be persisted - particularly in
> a program that generates lots of /related/ closures - while also
> keeping in mind that data may need to be both shared among multiple
> closures [not just among multiple functions in a common closure].
>
> It may be necessary, e.g., to pull data out of a stack context and
> heap allocate it instead.  That requires changing the stack context to
> be a pointer rather than a value, rewriting any functions that expect
> the value to use the pointer instead, and constructing new persistent
> "environment" structures that can find the relocated data.
>
> This can require a lot of effort by the compiler.
>
>
> OTOH, if the structure of the program is such that the closure's
> non-local data is guaranteed to be in scope when the closure is
> invoked, it often is simpler just to rewrite closure functions to
> access that data via a pointer parameter, and change the call sites to
> pass the required pointer(s).
>
> The closure may still need a persistent enviroment, but this method
> reduces or eliminates the need for /chained/ environments, and having
> to rewrite other non-closure functions that happen to use the data.
>
> This also can require a lot of effort by the compiler, but the effort
> can be more focused on the closures, and less on "regular" code.
>
>
> What you really don't want in any case is to have to preserve entire
> stacks just to support creating closures.  It doesn't matter whether
> the stack is linear or a chain of heap allocated structures[*]. Some
> rewriting and data relocation (out of the stack) will be necessary in
> any case.
>
> [*] yes, this actually is done in some GC'd language implementations.
> When the stack shrinks, discarded contexts are cleaned up by the GC.

To address the last point first - I'm familiar with circumstances
where "stack" data might be held in heap-allocated parcels.  I think
that possibility is orthogonal to the main issue, but in any case
I'm aware of the need to use extra-stack memory in some cases.

Returning to the main area of discussion - it occurs to me that we
may have different operational assumptions about the situations
where nested functions (or lambda expressions) are called.  In
particular, there is an important distinction between a call where
it is known which nested function/lambda is being called, and a call
where that is not known, for example by virtue of having been passed
as a function argument, with the call being done through a formal
parameter.  This distinction is analogous to calling an outside
function using its name versus calling a function through pointer
to function, where it isn't known what the pointer might point to.
When calling a function using the function's name, it is possible to
expand the function body inline.  (The inline expansion might be
done at link time, but conceptually that is no different.)

Conversely, when calling through a pointer-to-function, doing an
inline expansion isn't feasible in general, because we don't know
what function is going to be called, and also there might be more
than one.  The same sort of distinction occurs with calls to nested
functions (or equivalently lambdas).

The key point is that when packaging up a nested function plus data
into a closure, they all have to look the same:  one pointer to
function and one pointer to data.  That's because down the line the
ultimate caller doesn't know where the closure came from, so all
closures have to be structurally identical.

When I talk about closures, my built-in assumption is that what is
being talked about is the don't-know-who-is-being-called case.  Any
direct call to a nested function doesn't need a closure (there might
be one as a matter of convenience, but there doesn't have to be), so
any idea of adjusting call the call sites doesn't apply when we're
talking about closures (again, to be clear, in the way I use the
term closure).

My sense now is that you are talking (mostly? exclusively?) about
the direct call case.  Is that a fair read of your comments?

Thread

Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-06 14:57 +0100
  Re: Calling conventions (particularly 32-bit ARM) Theo <theom+news@chiark.greenend.org.uk> - 2025-01-06 15:23 +0000
    Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-07 09:22 +0100
  Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 15:32 +0000
    Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 20:19 +0000
      Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-07 10:09 +0100
        Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 23:23 +0000
          Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 23:35 +0000
            Re: Calling conventions (particularly 32-bit ARM) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-07 15:42 -0800
              Re: Calling conventions (particularly 32-bit ARM) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-07 20:01 -0800
            Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-08 01:38 +0000
    Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-07 09:49 +0100
  Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 20:10 +0000
    Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-07 02:11 +0000
      Re: Calling conventions (particularly 32-bit ARM) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-01-07 06:53 +0000
      Re: Calling conventions (particularly 32-bit ARM) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-12 12:10 -0800
        Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-12 20:41 +0000
        Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-13 01:20 +0000
          Re: Calling conventions (particularly 32-bit ARM) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-14 09:40 -0800
            Re: Calling conventions (particularly 32-bit ARM) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-14 19:18 +0100
              Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-14 23:48 +0200
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 23:27 +0000
                Re: Calling conventions (particularly 32-bit ARM) John Levine <johnl@taugh.com> - 2025-01-15 03:31 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-15 16:50 +0000
                Re: Calling conventions (particularly 32-bit ARM) John Levine <johnl@taugh.com> - 2025-01-15 22:03 +0000
                Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-16 03:02 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 15:08 +0000
                Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-16 16:24 +0000
        Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-13 21:33 +0000
          Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 06:48 +0000
            Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 18:03 +0000
    Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2025-01-07 16:52 -0500
      Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-08 12:20 -0500
        Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-09 08:38 +0000
          Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-13 10:55 -0500
      Re: Calling conventions (particularly 32-bit ARM) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:09 -0800
        Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2025-01-28 22:53 -0500
          Re: Calling conventions (particularly 32-bit ARM) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-14 20:40 -0800
            Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2026-02-17 15:35 -0500
              Re: Calling conventions (particularly 32-bit ARM) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-14 09:34 -0700
                Re: Calling conventions (particularly 32-bit ARM) George Neuner <gneuner2@comcast.net> - 2026-03-24 17:20 -0400
    Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-08 12:34 -0500
      Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-08 20:19 +0000
      Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-08 22:08 +0000
        Re: Calling conventions (particularly 32-bit ARM) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-08 18:20 -0500
          Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-09 00:11 +0000
          Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-09 07:23 +0000
            Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-09 10:07 +0000
              Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-10 08:24 +0000
            Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-09 20:48 +0000
              Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-09 21:23 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-10 01:08 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-10 09:19 +0000
            Re: Calling conventions (particularly 32-bit ARM) antispam@fricas.org (Waldek Hebisch) - 2025-01-10 08:33 +0000
              Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-10 10:25 +0000
                Re: Calling conventions (particularly 32-bit ARM) John Levine <johnl@taugh.com> - 2025-01-10 15:17 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-13 02:10 +0000
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-13 14:19 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-13 18:02 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-13 19:00 +0000
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-13 21:53 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-13 22:02 +0000
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-13 22:40 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 02:32 +0000
                Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-14 15:08 +0100
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 14:22 +0000
                Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-14 16:41 +0200
                Re: Calling conventions (particularly 32-bit ARM) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-14 18:02 +0000
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 18:15 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 18:19 +0000
                Re: Calling conventions (particularly 32-bit ARM) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-14 19:39 +0100
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 19:14 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 20:01 +0000
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 22:05 +0000
                Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 15:23 -0800
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 23:39 +0000
                Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 16:59 -0800
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 23:40 +0000
                Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 17:11 -0800
                Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-15 00:09 +0200
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-14 19:08 +0000
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 19:24 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 20:31 +0000
                Re: Calling conventions (particularly 32-bit ARM) Michael S <already5chosen@yahoo.com> - 2025-01-14 23:13 +0200
                Re: Calling conventions (particularly 32-bit ARM) mitchalsup@aol.com (MitchAlsup1) - 2025-01-15 00:47 +0000
                Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-14 06:20 +0000
                Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-14 15:05 +0100
                Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-14 14:39 +0000
                Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-14 16:50 +0100
                Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 15:32 -0800
                Re: Calling conventions (particularly 32-bit ARM) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 00:14 -0800
              Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-10 14:43 +0000
            Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-10 18:39 +0100
              Re: Calling conventions (particularly 32-bit ARM) scott@slp53.sl.home (Scott Lurndal) - 2025-01-10 18:39 +0000
                Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-12 14:55 +0100
              Re: Calling conventions (particularly 32-bit ARM) Thomas Koenig <tkoenig@netcologne.de> - 2025-01-10 19:19 +0000
                Re: Calling conventions (particularly 32-bit ARM) David Brown <david.brown@hesbynett.no> - 2025-01-12 14:59 +0100

csiph-web