On 2023-10-19, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 10/19/2023 12:20 PM, Kaz Kylheku wrote:
>> On 2023-10-19, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 19.10.2023 um 20:06 schrieb Kaz Kylheku:
>>>
>>>> Can you point to any documentation (MSDN?) that would give us confidence
>>>> that all which happened is a committed, robust feature that will work
>>>> across different versions of MSVC, with different code generation
>>>> options?
>>>
>>> Which option do you think would make MSVC drop the optimization barrier
>>> of volatile function pointers? The only volatile compiler option is
>>> ISO or MSVC volatile behaviour.
>>
>> Possibly, options that turn off optimization entirely, so that the barrier is not
>> considered.
>>
>> It's the wrong question. What piece of documentation specifies that
>> there is such an optimization barrier? Not just the optimization
>> barrier, but an optimization barrier that causes calling convention
>> attributes from a pointer to regenerate the called function body.
>>
>> Where did you get this belief?
>>
>> It is really weird. It similar to a situation like:
>>
>> struct foo { int x; int y } foo_obj = { 1, 2 };
>> struct bar { int y; int x };
>>
>> bar *volatile bar_ptr = (struct bar *) &foo_obj;
> ^^^^^^^^^^^^^^^^^
>
> Nasal demons regardless of volatile?

Yes; like in the original code. Calling a function through
incompatible calling conventions is (compiler-specific) nasal demons
(unless the situation is documented otherwise).

It seems like an unintended fluke that the inlining and
deinlining of the function squeezes out that problem.

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 but the lambda
is compiled twice.

On 10/20/23 3:19 AM, Bonita Montero 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 but the lambda
> is compiled twice.

No, the compiler seems to decide to create a conversion thunk to fix the
calling convention and then includes the lambda inline in that thunk.

It "Compiled" it once into the internal coding, but generated code
twice, as it was used inline twice.

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.

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.

Am 20.10.2023 um 11:47 schrieb Richard Damon:

> No, the compiler seems to decide to create a conversion thunk to fix the
> calling convention and then includes the lambda inline in that thunk.

No, theres no CALL inside my assembly. And for parameters which are
non-trivial objects that are on the stack this wouldn't work since
they would have to be copy-constructed; no one would accept that.

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.

Am 20.10.2023 um 16:50 schrieb Kaz Kylheku:

> Uh, yes it obviously is! The lambda is declared without any calling
> conventions attributes, but the function pointer has them.

The lambda is compiled for each destination pointer's calling convention.

> Are the tokens lexically analyzed twice?

As I described both compiled functions to the same and share
static and thread-local variables.

Rest unread.

On 2023-10-20, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 20.10.2023 um 16:50 schrieb Kaz Kylheku:
>
>> Uh, yes it obviously is! The lambda is declared without any calling
>> conventions attributes, but the function pointer has them.
>
> The lambda is compiled for each destination pointer's calling convention.

At this point you're just stringing together computer sciency words.

--
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.

Am 20.10.2023 um 18:06 schrieb Kaz Kylheku:

> At this point you're just stringing together computer sciency words.

The calling convention is part of the function pointer.

In article <uguai0$16sc9$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 20.10.2023 um 18:06 schrieb Kaz Kylheku:
>
>> At this point you're just stringing together computer sciency words.
>
>The calling convention is part of the function pointer.
>
>

At this point you're just stringing together computer sciency words.

Quoting The Rockford Files:

We're ghosting at 9600 Kbaud.

--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

On 10/20/23 8:59 AM, Bonita Montero wrote:
> Am 20.10.2023 um 11:47 schrieb Richard Damon:
>
>> No, the compiler seems to decide to create a conversion thunk to fix
>> the calling convention and then includes the lambda inline in that thunk.
>
> No, theres no CALL inside my assembly. And for parameters which are
> non-trivial objects that are on the  stack this wouldn't work since
> they would have to be copy-constructed; no one would accept that.

So, you don't understand what it means to inline code?

Or, how thunks work.

Am 21.10.2023 um 04:16 schrieb Richard Damon:

> So, you don't understand what it means to inline code?

I've described why the "invoker" can never be a separate function.

Am 20.10.2023 um 22:07 schrieb Kenny McCormack:

> In article <uguai0$16sc9$1@dont-email.me>,

> Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> The calling convention is part of the function pointer.

> At this point you're just stringing together computer sciency words.
> Quoting The Rockford Files:

Look at this:

int (__fastcall *volatile pFnFastcall)( int ) = lambda;
int (__stdcall *volatile pFnStdcall)( int ) = lambda;

This are functin pointers with separate calling conventions.

On 10/20/23 11:02 PM, Bonita Montero wrote:
> Am 21.10.2023 um 04:16 schrieb Richard Damon:
>
>> So, you don't understand what it means to inline code?
>
> I've described why the "invoker" can never be a separate function.
>

Its "called" by the code, so it IS a "function" at the assembly level.

Why do you disagree with clear facts?

Have you tried doing the same thing with a function that can not be
inlined?

Am 21.10.2023 um 17:38 schrieb Richard Damon:

> Its "called" by the code, so it IS a "function" at the assembly level.

Non-trivial objects would have to be copied, so this "invoker"
always inlines.

On 10/21/23 10:40 AM, Bonita Montero wrote:
> Am 21.10.2023 um 17:38 schrieb Richard Damon:
>
>> Its "called" by the code, so it IS a "function" at the assembly level.
>
> Non-trivial objects would have to be copied, so this "invoker"
> always inlines.
>

WHAT non-trival objects? Your example only has ints

Also, tail call elimination can often get rid of some of the copies.

Am 21.10.2023 um 19:54 schrieb Richard Damon:

> WHAT non-trival objects? Your example only has ints

I wanted to describe why the "invoker" nearly every time must inline
the lambda because non-trivial objects from the stack couldn't be
copied. I guess MSVC never does that so the name invoker is misleading.

> Also, tail call elimination can often get rid of some of the copies.

Call tail elimination doesn't work if you have different distribution
of parameters on the stack and in the registers.

On 10/21/23 11:34 AM, Bonita Montero wrote:
> Am 21.10.2023 um 19:54 schrieb Richard Damon:
>
>> WHAT non-trival objects? Your example only has ints
>
> I wanted to describe why the "invoker" nearly every time must inline
> the lambda because non-trivial objects from the stack couldn't be
> copied. I guess MSVC never does that so the name invoker is misleading.
>
>> Also, tail call elimination can often get rid of some of the copies.
>
> Call tail elimination doesn't work if you have different distribution
> of parameters on the stack and in the registers.
>
>

But in this case it made it work! so you are wrong.

Am 21.10.2023 um 21:45 schrieb Richard Damon:

> But in this case it made it work! so you are wrong.

It may work, but actually there's no real "invoker".

On 10/21/23 7:18 PM, Bonita Montero wrote:
> Am 21.10.2023 um 21:45 schrieb Richard Damon:
>
>> But in this case it made it work! so you are wrong.
>
> It may work, but actually there's no real "invoker".
>

Then why was the symbol called an "invoker"?

Am 22.10.2023 um 04:28 schrieb Richard Damon:
> On 10/21/23 7:18 PM, Bonita Montero wrote:
>> Am 21.10.2023 um 21:45 schrieb Richard Damon:
>>
>>> But in this case it made it work! so you are wrong.
>>
>> It may work, but actually there's no real "invoker".
>>
>
> Then why was the symbol called an "invoker"?

The lambda can have an arbitrary size, it is always inlined.

On 2023-10-22, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 22.10.2023 um 04:28 schrieb Richard Damon:
>> On 10/21/23 7:18 PM, Bonita Montero wrote:
>>> Am 21.10.2023 um 21:45 schrieb Richard Damon:
>>>
>>>> But in this case it made it work! so you are wrong.
>>>
>>> It may work, but actually there's no real "invoker".
>>>
>>
>> Then why was the symbol called an "invoker"?
>
> The lambda can have an arbitrary size, it is always inlined.
>
I don't think so...

--

7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/

On 10/21/23 9:53 PM, Bonita Montero wrote:
> Am 22.10.2023 um 04:28 schrieb Richard Damon:
>> On 10/21/23 7:18 PM, Bonita Montero wrote:
>>> Am 21.10.2023 um 21:45 schrieb Richard Damon:
>>>
>>>> But in this case it made it work! so you are wrong.
>>>
>>> It may work, but actually there's no real "invoker".
>>>
>>
>> Then why was the symbol called an "invoker"?
>
> The lambda can have an arbitrary size, it is always inlined.
>

Your lambda has a fixed code, not arbitrary size.

In fact, it is likely that it was because your particular lambda was
small, that it was made to be inline.

Lambdas define a function object, which can be created inline or out of
line.

Am 22.10.2023 um 16:12 schrieb Richard Damon:

> On 10/21/23 9:53 PM, Bonita Montero wrote:

>> The lambda can have an arbitrary size, it is always inlined.

> Your lambda has a fixed code, not arbitrary size.

What I wanted to say is that the lambda's size can be arbitrary
without having s separate invoker.

> In fact, it is likely that it was because your particular lambda was
> small, that it was made to be inline.

I did my own index_sequence<...> vs. function-object loop-unrolling
with 1'000 increments of an atomic_char inside the lambda; it was
still inlined.

> Lambdas define a function object, which can be created inline or out of
> line.

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.