Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #92556 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-10-11 05:30 +0200 |
| Last post | 2023-10-25 23:12 -0700 |
| Articles | 20 on this page of 134 — 12 participants |
Back to article view | Back to comp.lang.c++
What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 05:30 +0200
Re: What does this code print ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-11 14:03 +0100
Re: What does this code print ? gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-11 13:12 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 19:22 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-11 17:41 +0000
Re: What does this code print ? Bo Persson <bo@bo-persson.se> - 2023-10-11 20:24 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 05:24 +0200
Re: What does this code print ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-13 17:53 +0100
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-13 12:12 -0400
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-13 17:27 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:52 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 11:26 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:08 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-15 12:55 -0700
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-15 22:19 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-18 20:58 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 19:21 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 12:41 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 12:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 05:25 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-12 20:50 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 08:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-13 12:15 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:53 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 11:26 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:00 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:15 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:47 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-17 11:34 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-13 16:34 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-13 13:12 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-14 02:36 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-13 20:44 -0700
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-14 11:51 +0300
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-17 11:35 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-17 20:06 +0000
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-18 11:43 +0300
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-18 17:29 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-18 11:31 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-19 14:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:54 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-14 18:05 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 14:58 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 08:58 +0200
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-14 12:47 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:07 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:12 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:16 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:35 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:48 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:04 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 19:58 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 14:39 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 19:58 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 18:06 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:11 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 19:20 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 16:06 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-19 14:45 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 23:26 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 09:19 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-20 05:47 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 17:59 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-20 19:16 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 08:02 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 08:38 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 19:40 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 10:54 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 20:34 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 12:45 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-22 04:18 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 19:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-22 06:53 +0200
Re: What does this code print ? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-10-22 09:59 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-22 07:12 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-23 19:05 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-23 10:40 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 16:03 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 07:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 17:01 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 08:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 18:27 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 10:05 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:08 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 10:39 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 20:25 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-24 19:48 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 10:54 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 08:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 17:57 +0200
Re: What does this code print ? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-10-24 16:40 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:07 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-24 15:25 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 08:34 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-24 16:34 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:05 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 14:50 +0000
Re: What does this code print ? Bo Persson <bo@bo-persson.se> - 2023-10-20 17:34 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 15:59 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 18:00 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 16:06 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 18:40 +0200
Re: What does this code print ? gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-20 20:07 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 08:04 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:35 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:08 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:02 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 14:43 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:02 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-15 14:36 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 18:15 +0200
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-15 22:23 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:51 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:08 -0400
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:25 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-14 11:33 -0700
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-14 21:54 +0300
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-14 11:56 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-24 15:53 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 15:07 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 08:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 18:01 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 09:21 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 18:24 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 11:23 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-25 15:02 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-26 07:13 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 23:09 -0700
Re: What does this code print ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-25 23:55 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-25 15:01 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-26 07:15 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 23:12 -0700
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-24 17:01 +0200 |
| Message-ID | <uh8m8i$r6m$1@dont-email.me> |
| In reply to | #95112 |
Am 24.10.2023 um 16:28 schrieb Richard Damon: > Why do you say that? The "invoker" is a function created to invoke the > designated function in an environment (calling convention) that the > function can not directly handle. The actual lambda is always inlined. > "invoking" doesn't need a "call" instruction, as when you invoke an > "inline" function, the function is just put there. Then the term in invoker doesn't make sense. >> The calling operator of a lambda is inline if it is mutable or >> const inline if it is non-mutable. But we don't discuss C++ but >> the behaviour of a specific platform. > So, you said that mutability affected inlining. No, you went off-topic and I responeded to that. Then you made the connection to the actual topic, not me.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-24 08:28 -0700 |
| Message-ID | <uh8nrc$2ld7l$1@i2pn2.org> |
| In reply to | #95125 |
On 10/24/23 8:01 AM, Bonita Montero wrote: > Am 24.10.2023 um 16:28 schrieb Richard Damon: > >> Why do you say that? The "invoker" is a function created to invoke the >> designated function in an environment (calling convention) that the >> function can not directly handle. > > The actual lambda is always inlined. Then you agree that there is ONE lambda function (inlined twice) inlined within two invoker wrappers, not two versions of the lambda "compiled' with different calling conventions different than the one it was declared with. > >> "invoking" doesn't need a "call" instruction, as when you invoke an >> "inline" function, the function is just put there. > > Then the term in invoker doesn't make sense. Then "calling a function" that is inline doesn't make sense either. In fact, "invoking" has less connotation of using a phyical "CALL" instruction than the term call. To invoke something is to make it happen. That doesn't imply calling it. > >>> The calling operator of a lambda is inline if it is mutable or >>> const inline if it is non-mutable. But we don't discuss C++ but >>> the behaviour of a specific platform. > >> So, you said that mutability affected inlining. > > No, you went off-topic and I responeded to that. > Then you made the connection to the actual topic, not me. > Maybe you don't understand enough to understand the topicality of my statement. YOU claimed "mutability" affected inlining. I pointed out that it isn't defined to do that.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-24 18:27 +0200 |
| Message-ID | <uh8r8p$28od$1@dont-email.me> |
| In reply to | #95146 |
Am 24.10.2023 um 17:28 schrieb Richard Damon: > Then you agree that there is ONE lambda function (inlined twice) inlined > within two invoker wrappers, not two versions of the lambda "compiled' > with different calling conventions different than the one it was > declared with. It's two functions with two calling conventions sharing the same data. An invoker is some kind of stub-code for each calling convention calling a shared function; so the term invoker is misleading here. > YOU claimed "mutability" affected inlining. That's the connection you made.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-24 10:05 -0700 |
| Message-ID | <uh8tho$2ltqv$1@i2pn2.org> |
| In reply to | #95162 |
On 10/24/23 9:27 AM, Bonita Montero wrote: > Am 24.10.2023 um 17:28 schrieb Richard Damon: > >> Then you agree that there is ONE lambda function (inlined twice) >> inlined within two invoker wrappers, not two versions of the lambda >> "compiled' with different calling conventions different than the one >> it was declared with. > > It's two functions with two calling conventions sharing the same data. > An invoker is some kind of stub-code for each calling convention calling > a shared function; so the term invoker is misleading here. But that is EXACTLY what is happening. We have two "stub" functions, the two "invoker" functions, one for each calling convention, "calling" (via inline expansion) the shared function. How does that not match what you see? > >> YOU claimed "mutability" affected inlining. > > That's the connection you made. >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-24 19:08 +0200 |
| Message-ID | <uh8tli$2s0a$2@dont-email.me> |
| In reply to | #95181 |
Am 24.10.2023 um 19:05 schrieb Richard Damon: > But that is EXACTLY what is happening. No, there's no stub-/proxy-code, it's like you implemented two idential functions with different calling conventions.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-24 10:39 -0700 |
| Message-ID | <uh8vgs$2ltqv$2@i2pn2.org> |
| In reply to | #95183 |
On 10/24/23 10:08 AM, Bonita Montero wrote: > Am 24.10.2023 um 19:05 schrieb Richard Damon: > >> But that is EXACTLY what is happening. > > No, there's no stub-/proxy-code, it's like you implemented > two idential functions with different calling conventions. > So, how is that different than two stubs with two copies of the same inline code? Since they are named that way, it seems to be what it is.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-24 20:25 +0200 |
| Message-ID | <uh927h$41im$1@dont-email.me> |
| In reply to | #95190 |
Am 24.10.2023 um 19:39 schrieb Richard Damon: > So, how is that different than two stubs with two copies of the same > inline code? It's not copied code as you can see from my disassembly.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-24 19:48 +0000 |
| Message-ID | <20231024123628.971@kylheku.com> |
| In reply to | #95213 |
On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 24.10.2023 um 19:39 schrieb Richard Damon:
>
>> So, how is that different than two stubs with two copies of the same
>> inline code?
>
> It's not copied code as you can see from my disassembly.
It is quite usual for calls to inline functions not to appear identical.
The code is integrated into the caller, and then subject to
transformations as if were part of the caller's code.
Differences in calling convention would be something handled close to
the compiler code-generating back end.
You should re-examine critically what you mean by "compile twice",
and try to formalize it.
Compiling is everything from recognizing preprocessor tokens and
expanding macros and directives, to writing a .o or .obj file to disk;
even linking objects together to make an executable is sometimes
discussed as part of "compiling".
Code motion like loop unrolling and inlining is not usually discussed in
terms of "compiling twice", though it probaby does result in some
compiler passes being done twice on the different copies of the code.
If by "compiled twice" you mean that some code-generating back end
had to apply its work twice to the copies of the code, you are are
almost certainly right.
The idea that what is going on that code is distinct from inlining (that
"twice compiling" is going on there, but not in inlining) doesn't hold
water.
What most likely happened is this: because of the volatile function
pointer the compiler generated thunks which call the lambda (those
"invokers"):
We can show that using pseudo-code:
Reformatted original, minus header file and namespace boilerplate:
int main()
{
auto lambda = []( int a ) -> int
{
thread_local int i = 0;
return i++ + a;
};
int (__fastcall *volatile pFnFastcall)( int ) = lambda;
int (__stdcall *volatile pFnStdcall)( int ) = lambda;
cout << pFnFastcall( 10 ) << endl;
cout << pFnStdcall( 9 ) << endl;
}
What the compiler might have done, shown as pseudo-code:
int main()
{
auto lambda = []( int a ) -> int
{
thread_local int i = 0;
return i++ + a;
};
// hypothetical, compiler-generated code schema:
auto __notinline __fastcall invoker001 = []( int a ) -> int
{
return lambda(a); // lambda gets inlined
};
auto __notinline __stdcall invoker002 = []( int a ) -> int
{
return lambda(a); // lambda gets inlined
};
int (__fastcall *volatile pFnFastcall)( int ) = invoker001;
int (__stdcall *volatile pFnStdcall)( int ) = invoker002;
cout << pFnFastcall( 10 ) << endl;
cout << pFnStdcall( 9 ) << endl;
}
The invokers are real functions which are called. They inline
the lambda.
The invokers have matching calling conventions, propagated from
the volatile pointers. So that's where the adaptation comes from
to the calling conventions.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-25 10:54 +0200 |
| Message-ID | <uhal49$l1h3$1@dont-email.me> |
| In reply to | #95225 |
Am 24.10.2023 um 21:48 schrieb Kaz Kylheku: > It is quite usual for calls to inline functions not to appear identical. That's true in this case because the "invoker" gets its values in a different way. Nevertheless the term invoker is misleading if the "invoked" function is always inlined. I did some loop unrolling inside the lambda, producing about 2.000 instructions and the lambda was still inlined. I guess If MSVC doesn't have a separate invoker with so much code there's never a separate invoker. And with non-trivial parameters there might be unexpectedd side effects if there's a non-inlined called function like an out of memory error. So I gues MS knows that and con- siders calling a separate functio too dangerous or intransparent.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-25 08:43 -0700 |
| Message-ID | <uhbd3g$2mvvu$2@i2pn2.org> |
| In reply to | #95686 |
On 10/25/23 1:54 AM, Bonita Montero wrote: > Am 24.10.2023 um 21:48 schrieb Kaz Kylheku: > >> It is quite usual for calls to inline functions not to appear identical. > > That's true in this case because the "invoker" gets its values in > a different way. Nevertheless the term invoker is misleading if the > "invoked" function is always inlined. I did some loop unrolling inside > the lambda, producing about 2.000 instructions and the lambda was still > inlined. I guess If MSVC doesn't have a separate invoker with so much > code there's never a separate invoker. And with non-trivial parameters > there might be unexpectedd side effects if there's a non-inlined called > function like an out of memory error. So I gues MS knows that and con- > siders calling a separate functio too dangerous or intransparent. > Yes, "invoker" may be a bit misleading, but it is the term that was chosen, and the terminology doesn't change just because the invoked function happens to be inlined. As someone else mentioned, perhaps a more common term is "trampoline", but that term is longer, and actually isn't as descriptive of a term.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-25 17:57 +0200 |
| Message-ID | <uhbdth$rqvq$1@dont-email.me> |
| In reply to | #95821 |
Am 25.10.2023 um 17:43 schrieb Richard Damon: > Yes, "invoker" may be a bit misleading, but it is the term that was > chosen, and the terminology doesn't change just because the invoked > function happens to be inlined. The term becomes rather metaphoric with that.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@icloud.com> |
|---|---|
| Date | 2023-10-24 16:40 +0000 |
| Message-ID | <rsSZM.101793$HwD9.74381@fx11.iad> |
| In reply to | #95125 |
On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 24.10.2023 um 16:28 schrieb Richard Damon: > >> Why do you say that? The "invoker" is a function created to invoke the >> designated function in an environment (calling convention) that the >> function can not directly handle. > > The actual lambda is always inlined. > Try to compile without optimisations... -- 7-77-777, Evil Sinner! https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-24 19:07 +0200 |
| Message-ID | <uh8tjq$2s0a$1@dont-email.me> |
| In reply to | #95170 |
Am 24.10.2023 um 18:40 schrieb Branimir Maksimovic: > Try to compile without optimisations... This could only make a difference where the parameters are trivial types. Otherwise objects would have to be copied and you would have side effects like allocation errors.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-10-24 15:25 +0000 |
| Message-ID | <xlRZM.207977$rbid.58230@fx18.iad> |
| In reply to | #95112 |
Richard Damon <richard@damon-family.org> writes: >On 10/24/23 7:03 AM, Bonita Montero wrote: >> Am 23.10.2023 um 19:40 schrieb Richard Damon: >> >>> So? In this case we got an invoker, because we needed something to >>> handle the calling convention difference. >> >> It's called invoker, but the actual lambda is always inlined. >> So this term is misleading here. > >Why do you say that? The "invoker" is a function created to invoke the >designated function in an environment (calling convention) that the >function can not directly handle. This is often also called a trampoline.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-24 08:34 -0700 |
| Message-ID | <uh8o62$2ld7m$2@i2pn2.org> |
| In reply to | #95143 |
On 10/24/23 8:25 AM, Scott Lurndal wrote: > Richard Damon <richard@damon-family.org> writes: >> On 10/24/23 7:03 AM, Bonita Montero wrote: >>> Am 23.10.2023 um 19:40 schrieb Richard Damon: >>> >>>> So? In this case we got an invoker, because we needed something to >>>> handle the calling convention difference. >>> >>> It's called invoker, but the actual lambda is always inlined. >>> So this term is misleading here. >> >> Why do you say that? The "invoker" is a function created to invoke the >> designated function in an environment (calling convention) that the >> function can not directly handle. > > This is often also called a trampoline. > Yes, but since the program map showed a name of invoker, that is the term being used. I think Bonita might have a brain melt to talk about a trampoline named with the term invoker.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-24 16:34 +0000 |
| Message-ID | <20231024093342.675@kylheku.com> |
| In reply to | #95091 |
On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 23.10.2023 um 19:40 schrieb Richard Damon: > >> So? In this case we got an invoker, because we needed something to >> handle the calling convention difference. > > It's called invoker, but the actual lambda is always inlined. Well, that's an about face. Near the start of the topic you were vehemently denying that there was inlining. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-24 19:05 +0200 |
| Message-ID | <uh8tg6$2rh0$1@dont-email.me> |
| In reply to | #95165 |
Am 24.10.2023 um 18:34 schrieb Kaz Kylheku: > On 2023-10-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 23.10.2023 um 19:40 schrieb Richard Damon: >> It's called invoker, but the actual lambda is always inlined. > Well, that's an about face. Near the start of the topic you were > vehemently denying that there was inlining. An invoker is some kind of stub-/proxy-code, there's nothing like that here.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-20 14:50 +0000 |
| Message-ID | <20231020074449.603@kylheku.com> |
| In reply to | #94218 |
On 2023-10-20, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 20.10.2023 um 01:26 schrieb Kaz Kylheku: > >> Yes; like in the original code. Calling a function through >> incompatible calling conventions is (compiler-specific) >> nasal demons (unless the situation is documented otherwise). > > The calling convention isn't incompatible Uh, yes it obviously is! The lambda is declared without any calling conventions attributes, but the function pointer has them. > but the lambda is compiled twice. That has no meaning without defining your terms. Are the tokens lexically analyzed twice? Is the syntax parsed twice? Or is the body of the lambda checked twice for type errors? There is evidence that some code is generated twice. If we have for (i = 0; i < N; i++) loop and we see four copies of the body in the machine code, with a loop index being incremented by 4, we don't say that the loop body was compiled four times. There may have been four copies of some intermediate code which got code-generated four times. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2023-10-20 17:34 +0200 |
| Message-ID | <kpfl13F20fpU1@mid.individual.net> |
| In reply to | #94254 |
On 2023-10-20 at 16:50, Kaz Kylheku wrote: > On 2023-10-20, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 20.10.2023 um 01:26 schrieb Kaz Kylheku: >> >>> Yes; like in the original code. Calling a function through >>> incompatible calling conventions is (compiler-specific) >>> nasal demons (unless the situation is documented otherwise). >> >> The calling convention isn't incompatible > > Uh, yes it obviously is! The lambda is declared without any calling > conventions attributes, but the function pointer has them. > The "trick" is that MSVC in x64 mode only offers one calling convention, so it is always the same. The compiler assumes that the attributes are some leftovers from 32-bit code, so they can be ignored.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-20 15:59 +0000 |
| Message-ID | <20231020085713.834@kylheku.com> |
| In reply to | #94259 |
On 2023-10-20, Bo Persson <bo@bo-persson.se> wrote: > On 2023-10-20 at 16:50, Kaz Kylheku wrote: >> On 2023-10-20, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 20.10.2023 um 01:26 schrieb Kaz Kylheku: >>> >>>> Yes; like in the original code. Calling a function through >>>> incompatible calling conventions is (compiler-specific) >>>> nasal demons (unless the situation is documented otherwise). >>> >>> The calling convention isn't incompatible >> >> Uh, yes it obviously is! The lambda is declared without any calling >> conventions attributes, but the function pointer has them. >> > > The "trick" is that MSVC in x64 mode only offers one calling convention, > so it is always the same. No, that's not it; the discussion is definitely about that code being compiled x86 where those extensions are relevant. The example machine language disassembly listing actually shows two copies of the generated code, which are being called according to the two different convntions, and access the argument accordingly: the fastcall generation gets it from a register, whereas the stdcall gets it from the stack. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web