Hi,

Which book or tutorial would you recommend for standard C threads
introduced in C11 ?

Am 11.12.2021 um 07:36 schrieb Mehdi Amini:
> Hi,
>
> Which book or tutorial would you recommend for standard C threads
> introduced in C11 ?

Better learn C++; C++11 threads are magnitudes more convenient.

In article <sp1k0a$b9b$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 11.12.2021 um 07:36 schrieb Mehdi Amini:
>> Hi,
>>
>> Which book or tutorial would you recommend for standard C threads
>> introduced in C11 ?
>
>Better learn C++; C++11 threads are magnitudes more convenient.
>

Better still: Hire someone else to write your programs for you.

Then you don't have to learn anything.

Much, much more convenient.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/DanQuayle

On Saturday, December 11, 2021 at 3:37:00 AM UTC-3, Mehdi Amini Valashani son of Bahram wrote:
> Hi,
>
> Which book or tutorial would you recommend for standard C threads
> introduced in C11 ?

Some sources:

- https://en.cppreference.com/w/c/thread

- the C standard

- Threads in C are based on the C++ version.
You if you learn the C++ version then C is similar in concepts. (not in code)
https://www.cplusplusconcurrencyinaction.com/

C threads are not implemented in many compilers. I use this library:
https://tinycthread.github.io/

Am 13.12.2021 um 09:12 schrieb Kenny McCormack:
> In article <sp1k0a$b9b$1@dont-email.me>,
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 11.12.2021 um 07:36 schrieb Mehdi Amini:
>>> Hi,
>>>
>>> Which book or tutorial would you recommend for standard C threads
>>> introduced in C11 ?
>>
>> Better learn C++; C++11 threads are magnitudes more convenient.
>>
>
> Better still: Hire someone else to write your programs for you.

With C++ you've to learn a magnitude more than for C.
But you have much less code and the code is more
maintainable if you use the language properly.

Am 13.12.2021 um 18:16 schrieb Thiago Adams:

> - Threads in C are based on the C++ version.
No, both ways are based on the facilites the operating systems
supply to you, but C++ has a higher abstraction-level here.
But in C++ they're much more convenient to use. F.e. you can
simply have a lambda with captures a a thread-function. Or
supply a number of arguments directly to a thread function
through the constructor of std::thread / std::jthread. Or
you have full RAII-ness for locking.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 13.12.2021 um 18:16 schrieb Thiago Adams:
>
>> - Threads in C are based on the C++ version.
>No, both ways are based on the facilites the operating systems
>supply to you, but C++ has a higher abstraction-level here.
>But in C++ they're much more convenient to use.

Definitely arguable.

>F.e.

You should write z.b. or e.g. 'f.e.' is not a standard
abbreviation.

>you can simply have a lambda with captures a a thread-function.

Simply? If your thread function is so simple that it makes
sense to write it as a lambda, you probably should not be using
threads.

> Simply? If your thread function is so simple that it makes
> sense to write it as a lambda, you probably should not be
> using threads.

You're so silly to think lambdas are suitable only for simple things.
I regulary use complex lambdas as jthread-"functions" which inherit
the initiators context through [&].

Le 14/12/2021 à 18:43, Bonita Montero a écrit :
>> Simply? If your thread function is so simple that it makes
>> sense to write it as a lambda, you probably should not be
>> using threads.
>
> You're so silly to think lambdas are suitable only for simple things.
> I regulary use complex lambdas as jthread-"functions" which inherit
> the initiators context through [&].

We'd sure be curious to have a look at this. :D

Am 14.12.2021 um 19:23 schrieb Guillaume:
> Le 14/12/2021 à 18:43, Bonita Montero a écrit :
>>> Simply? If your thread function is so simple that it makes
>>> sense to write it as a lambda, you probably should not be
>>> using threads.
>>
>> You're so silly to think lambdas are suitable only for simple things.
>> I regulary use complex lambdas as jthread-"functions" which inherit
>> the initiators context through [&].
>
> We'd sure be curious to have a look at this. :D

Just long lambdas which use a lot of the inherited stackframe.

On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
> > Simply? If your thread function is so simple that it makes
> > sense to write it as a lambda, you probably should not be
> > using threads.
> You're so silly to think lambdas are suitable only for simple things.
> I regulary use complex lambdas as jthread-"functions" which inherit
> the initiators context through [&].
>
I write mainly procedural C++. But it's easier to pass a trivial little
lambda to std::sort than to write a free-standing comparison function.
I rarely write code which accepts lambdas, just as I rarely write code
which declares templates, though I call such code quite frequently.

Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>> Simply? If your thread function is so simple that it makes
>>> sense to write it as a lambda, you probably should not be
>>> using threads.
>> You're so silly to think lambdas are suitable only for simple things.
>> I regulary use complex lambdas as jthread-"functions" which inherit
>> the initiators context through [&].
>>
> I write mainly procedural C++. But it's easier to pass a trivial little
> lambda to std::sort than to write a free-standing comparison function.
> I rarely write code which accepts lambdas, just as I rarely write code
> which declares templates, though I call such code quite frequently.

I even use often templated lambdas.

On 15/12/2021 16:53, Bonita Montero wrote:
> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>> Simply? If your thread function is so simple that it makes
>>>> sense to write it as a lambda, you probably should not be
>>>> using threads.
>>> You're so silly to think lambdas are suitable only for simple things.
>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>> the initiators context through [&].
>>>
>> I write mainly procedural C++. But it's easier to pass a trivial little
>> lambda to std::sort than to write a free-standing comparison function.
>> I rarely write code which accepts lambdas, just as I rarely write code
>> which declares templates, though I call such code quite frequently.
>
> I even use often templated lambdas.

You would!

You just /have/ to use the most elaborate toys at your disposal -
preferably as many at the same time as possible - and combine them in
ways that make people's heads spin.

And yet you're always pushing the agenda that C++ somehow makes
everything a piece of cake!

Am 15.12.2021 um 18:26 schrieb Bart:
> On 15/12/2021 16:53, Bonita Montero wrote:
>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>> Simply? If your thread function is so simple that it makes
>>>>> sense to write it as a lambda, you probably should not be
>>>>> using threads.
>>>> You're so silly to think lambdas are suitable only for simple things.
>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>> the initiators context through [&].
>>>>
>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>> lambda to std::sort than to write a free-standing comparison function.
>>> I rarely write code which accepts lambdas, just as I rarely write code
>>> which declares templates, though I call such code quite frequently.
>>
>> I even use often templated lambdas.
>
> You would!
>
> You just /have/ to use the most elaborate toys at your disposal -
> preferably as many at the same time as possible - and combine
> them in ways that make people's heads spin.

I use lambdas mostly to prevent redundant code in functions. And
I use templated lambdas for the same purpose but in addition when
the lambda is performance-critical. The resulting code is still
more readable than having multiply specialized code in the function.

Bart <bc@freeuk.com> writes:
>On 15/12/2021 16:53, Bonita Montero wrote:
>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>> Simply? If your thread function is so simple that it makes
>>>>> sense to write it as a lambda, you probably should not be
>>>>> using threads.
>>>> You're so silly to think lambdas are suitable only for simple things.
>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>> the initiators context through [&].
>>>>
>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>> lambda to std::sort than to write a free-standing comparison function.
>>> I rarely write code which accepts lambdas, just as I rarely write code
>>> which declares templates, though I call such code quite frequently.
>>
>> I even use often templated lambdas.
>
>You would!
>
>You just /have/ to use the most elaborate toys at your disposal -
>preferably as many at the same time as possible - and combine them in
>ways that make people's heads spin.

And given the amount of time Bonita spends posting, I would
guess that most of the code written is for personal use, not
professional.

Am 15.12.2021 um 18:49 schrieb Scott Lurndal:
> Bart <bc@freeuk.com> writes:
>> On 15/12/2021 16:53, Bonita Montero wrote:
>>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>>> Simply? If your thread function is so simple that it makes
>>>>>> sense to write it as a lambda, you probably should not be
>>>>>> using threads.
>>>>> You're so silly to think lambdas are suitable only for simple things.
>>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>>> the initiators context through [&].
>>>>>
>>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>>> lambda to std::sort than to write a free-standing comparison function.
>>>> I rarely write code which accepts lambdas, just as I rarely write code
>>>> which declares templates, though I call such code quite frequently.
>>>
>>> I even use often templated lambdas.
>>
>> You would!
>>
>> You just /have/ to use the most elaborate toys at your disposal -
>> preferably as many at the same time as possible - and combine them in
>> ways that make people's heads spin.
>
> And given the amount of time Bonita spends posting, I would
> guess that most of the code written is for personal use, not
> professional.

My code isn't less readable because I use C++ partitially
in an unusual way. If everyone had this style in mind no
one would complain about that.

Am 15.12.2021 um 18:26 schrieb Bart:
> On 15/12/2021 16:53, Bonita Montero wrote:
>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>> Simply? If your thread function is so simple that it makes
>>>>> sense to write it as a lambda, you probably should not be
>>>>> using threads.
>>>> You're so silly to think lambdas are suitable only for simple things.
>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>> the initiators context through [&].
>>>>
>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>> lambda to std::sort than to write a free-standing comparison function.
>>> I rarely write code which accepts lambdas, just as I rarely write code
>>> which declares templates, though I call such code quite frequently.
>>
>> I even use often templated lambdas.
>
> You would!
>
> You just /have/ to use the most elaborate toys at your disposal -
> preferably as many at the same time as possible - and combine them in
> ways that make people's heads spin.
>
> And yet you're always pushing the agenda that C++ somehow makes
> everything a piece of cake!

That's an example of my lambda-style:

auto buildChain = [&]<CmdLineParams::type_t Type>( bool smtThreaded,
unsigned toThread )
{
auto updateStarts = [&]<typename MappingFn>( MappingFn mappingFn )
requires requires( MappingFn mappingFn, size_t i )
{
{ mappingFn( i ) } -> same_as<size_t>;
}
{
for( unsigned nThreads = 1; nThreads <= toThread; ++nThreads )
{
vector<link_t *> &starts = chainStarts[nThreads - 1];
double gap = (double)(ptrdiff_t)n / (int)nThreads;
for( unsigned t = 0; t != nThreads; ++t )
starts[t] = &links[mappingFn( (ptrdiff_t)((int)t * gap) )];
}
};
if constexpr( Type == CmdLineParams::LINEAR || Type ==
CmdLineParams::XLINEAR )
{
auto linearConcat = [&]<typename MappingFn>( MappingFn mappingFn )
requires requires( MappingFn mappingFn, size_t i )
{
{ mappingFn( i ) } -> same_as<size_t>;
}
{
for( size_t i = 0; i != n; ++i )
links[i].next = &links[mappingFn( mappingFn( i ) + 1 & idxMask)];
};
if constexpr( Type == CmdLineParams::LINEAR )
{
auto directMap = []( size_t i ) { return i; };
linearConcat( directMap );
updateStarts( directMap );
}
else
{
size_t inverter = (size_t)0x5555555555555555u & idxMask;
auto invertedMap = [&]( size_t i ) { return i ^ inverter; };
linearConcat( invertedMap );
updateStarts( invertedMap );
}
return;
}
unsigned l2ThrTlbBits = l2TlbBits - (unsigned)(smtThreaded && l2TlbBits),
l1ThrTlbBits = l1TlbBits - (unsigned)(smtThreaded && l1TlbBits);
unsigned l1Bits, l2Bits, outerBits;
size_t l2Mask, outerMask;
auto maskFromBits = []( unsigned bits ) -> size_t { return ((size_t)1
<< bits) - 1; };
if constexpr( Type == CmdLineParams::TLB_RANDOM )
if( bits > l2ThrTlbBits + pageBits )
outerBits = bits - (l2ThrTlbBits + pageBits),
outerMask = maskFromBits( outerBits ),
l2Bits = l2ThrTlbBits - l1ThrTlbBits,
l2Mask = maskFromBits( l2Bits ),
l1Bits = l1ThrTlbBits + pageBits - linkBits;
else if( bits > l1ThrTlbBits + pageBits )
outerBits = 0,
outerMask = 0,
l2Bits = bits - (l1ThrTlbBits + pageBits),
l2Mask = maskFromBits( l2Bits ),
l1Bits = l1ThrTlbBits + pageBits - linkBits;
else
outerBits = 0,
outerMask = 0,
l2Bits = 0,
l2Mask = 0,
l1Bits = bits - linkBits;
else
l1Bits = bits - linkBits;
auto flipIndex = [&]( size_t i ) -> size_t
{
static unsigned const SZT_BITS = sizeof(size_t) * CHAR_BIT;
size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
if constexpr( Type != CmdLineParams::TLB_RANDOM )
return rL1;
size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS - l2Bits & l2Mask,
rOuter = reverseBits( i >> l2Bits + l1Bits ) >> SZT_BITS -
outerBits & outerMask;
return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits + l1Bits);
};
for( size_t rI = 0; rI != n; ++rI )
links[rI].next = &links[flipIndex( flipIndex( rI ) + 1 & idxMask )];
updateStarts( flipIndex );
};

Without lambdas and even more templated lambdas the code
would become very complicated.

On 12/15/2021 9:49 AM, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 15/12/2021 16:53, Bonita Montero wrote:
>>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>>> Simply? If your thread function is so simple that it makes
>>>>>> sense to write it as a lambda, you probably should not be
>>>>>> using threads.
>>>>> You're so silly to think lambdas are suitable only for simple things.
>>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>>> the initiators context through [&].
>>>>>
>>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>>> lambda to std::sort than to write a free-standing comparison function.
>>>> I rarely write code which accepts lambdas, just as I rarely write code
>>>> which declares templates, though I call such code quite frequently.
>>>
>>> I even use often templated lambdas.
>>
>> You would!
>>
>> You just /have/ to use the most elaborate toys at your disposal -
>> preferably as many at the same time as possible - and combine them in
>> ways that make people's heads spin.
>
> And given the amount of time Bonita spends posting, I would
> guess that most of the code written is for personal use, not
> professional.

Especially with some of the errors in the posted code...

Here's another good example of using long lambdas:

auto gatherTLBs = [&]( bool update ) -> size_t
{
size_t nTLBs = 0;
auto push = [&]( bool l2, bool code, bool _4k, bool _2M4M, bool _1G,
unsigned n, unsigned ways, bool update )
{
if( !n || !ways )
return;
++nTLBs;
if( update )
tlbs.emplace_back( (uint8_t)l2 + 1, !code ? tlb_descr::type_t::DATA
: tlb_descr::type_t::CODE, _4k, _2M4M, _2M4M, _1G, n, ways );
};
static auto longWays = []( uint8_t ways ) -> unsigned { return ways
!= 0xFF ? ways : -1; };
static unsigned const shortWays[0x10] = { 0, 1, 2, 0, 4, 0, 8, 0, 16,
0, 32, 48, 64, 96, 128, (unsigned)-1 };
cpuid( regs, 0x80000005u, 0 );
push( false, false, true, false, false, regs[1] >> 16 & 0x0FF,
longWays( regs[1] >> 24 ), update );
push( false, false, false, true, false, regs[0] >> 16 & 0x0FF,
longWays( regs[0] >> 24 ), update );
push( false, true, true, false, false, regs[1] & 0xFF, longWays(
regs[1] >> 8 & 0xFF ), update );
push( false, true, false, true, false, regs[0] & 0xFF, longWays(
regs[0] >> 8 & 0xFF ), update );
cpuid( regs, 0x80000006u, 0 );
push( true, false, true, false, false, regs[1] >> 16 & 0x0FFF,
shortWays[regs[1] >> 28], update );
push( true, false, false, true, false, regs[0] >> 16 & 0x0FFF,
shortWays[regs[0] >> 28], update );
push( true, true, true, false, false, regs[1] & 0xFFF,
shortWays[regs[1] >> 12 & 0xF], update );
push( true, true, false, true, false, regs[0] & 0xFFF,
shortWays[regs[0] >> 12 & 0xF], update );
if( has1GPages() && maxExtCpuid >= 0x80000019u )
cpuid( regs, 0x80000019u, 0 ),
push( false, false, false, false, true, regs[0] >> 16 & 0xFFF,
shortWays[regs[0] >> 28], update ),
push( false, true, false, false, true, regs[0] & 0xFFF,
shortWays[regs[1] >> 12 & 0xF], update ),
push( true, false, false, false, true, regs[1] >> 16 & 0xFFF,
shortWays[regs[0] >> 28], update ),
push( true, true, false, false, true, regs[1] & 0xFFF,
shortWays[regs[1] >> 12 & 0xF], update );
return nTLBs;
};
tlbs.reserve( gatherTLBs( false ) );
gatherTLBs( true );

This function collects the TLB-sizes for AMD-CPUs. In one mode it just
counts the number of entries (update = false), in th other it fills the
vector tlbs. That prevents any reallocation of tlbs.
And the push lambda prevents a huge amount of redundant code.

On 16/12/2021 06:54, Bonita Montero wrote:
> Here's another good example of using long lambdas:
>
>         auto gatherTLBs = [&]( bool update ) -> size_t
>         {
>             size_t nTLBs = 0;
>             auto push = [&]( bool l2, bool code, bool _4k, bool _2M4M,
> bool _1G, unsigned n, unsigned ways, bool update )
>             {
>                 if( !n || !ways )
>                     return;
>                 ++nTLBs;
>                 if( update )
>                     tlbs.emplace_back( (uint8_t)l2 + 1, !code ?
> tlb_descr::type_t::DATA : tlb_descr::type_t::CODE, _4k, _2M4M, _2M4M,
> _1G, n, ways );
>             };
>             static auto longWays = []( uint8_t ways ) -> unsigned {
> return ways != 0xFF ? ways : -1; };
>             static unsigned const shortWays[0x10] = { 0, 1, 2, 0, 4, 0,
> 8, 0, 16, 0, 32, 48, 64, 96, 128, (unsigned)-1 };
>             cpuid( regs, 0x80000005u, 0 );
>             push( false, false, true, false, false, regs[1] >> 16 &
> 0x0FF, longWays( regs[1] >> 24 ), update );
>             push( false, false, false, true, false, regs[0] >> 16 &
> 0x0FF, longWays( regs[0] >> 24 ), update );
>             push( false, true, true, false, false, regs[1] & 0xFF,
> longWays( regs[1] >> 8 & 0xFF ), update );
>             push( false, true, false, true, false, regs[0] & 0xFF,
> longWays( regs[0] >> 8 & 0xFF ), update );
>             cpuid( regs, 0x80000006u, 0 );
>             push( true, false, true, false, false, regs[1] >> 16 &
> 0x0FFF, shortWays[regs[1] >> 28], update );
>             push( true, false, false, true, false, regs[0] >> 16 &
> 0x0FFF, shortWays[regs[0] >> 28], update );
>             push( true, true, true, false, false, regs[1] & 0xFFF,
> shortWays[regs[1] >> 12 & 0xF], update );
>             push( true, true, false, true, false, regs[0] & 0xFFF,
> shortWays[regs[0] >> 12 & 0xF], update );
>             if( has1GPages() && maxExtCpuid >= 0x80000019u )
>                 cpuid( regs, 0x80000019u, 0 ),
>                 push( false, false, false, false, true, regs[0] >> 16 &
> 0xFFF, shortWays[regs[0] >> 28], update ),
>                 push( false, true, false, false, true, regs[0] & 0xFFF,
> shortWays[regs[1] >> 12 & 0xF], update ),
>                 push( true, false, false, false, true, regs[1] >> 16 &
> 0xFFF, shortWays[regs[0] >> 28], update ),
>                 push( true, true, false, false, true, regs[1] & 0xFFF,
> shortWays[regs[1] >> 12 & 0xF], update );
>             return nTLBs;
>         };
>         tlbs.reserve( gatherTLBs( false ) );
>         gatherTLBs( true );
>
> This function collects the TLB-sizes for AMD-CPUs. In one mode it just
> counts the number of entries (update = false), in th other it fills the
> vector tlbs. That prevents any reallocation of tlbs.
> And the push lambda prevents a huge amount of redundant code.

Which bit is the lambda? If I create a more compact version so that I
can see the whole thing more easily:

auto gatherTLBs = [&](bool update ) -> size_t
{
size_t nTLBs = 0;
auto push = [&](bool l2, code, _4k, _2M4M, _1G, unsigned n, ways,
bool update )
{
if( !n || !ways )
return;
++nTLBs;
if( update )
tlbs.emplace_back( (uint8_t)l2 + 1, !code ? DATA : CODE,
_4k, _2M4M, _2M4M, _1G, n, ways );
};

static auto longWays = []( uint8_t ways ) -> unsigned { return ways
!= 0xFF ? ways : -1; };
static unsigned shortWays[0x10] = { 0, 1, 2, 0, 4, 0, 8, 0, 16,
0, 32, 48, 64, 96, 128, (unsigned)-1 };
cpuid( regs, 0x80000005u, 0 );
push( F, F, T, F, F, regs[1] >> 16 & 0x0FF, longWays( regs[1] >>
24 ), update );
push( F, F, F, T, F, regs[0] >> 16 & 0x0FF, longWays( regs[0] >>
24 ), update );
push( F, T, T, F, F, regs[1] & 0xFF, longWays( regs[1] >> 8 &
0xFF ), update );
push( F, T, F, T, F, regs[0] & 0xFF, longWays( regs[0] >> 8 &
0xFF ), update );
cpuid( regs, 0x80000006u, 0 );
push( T, F, T, F, F, regs[1] >> 16 & 0x0FFF, shortWays[regs[1] >>
28], update );
push( T, F, F, T, F, regs[0] >> 16 & 0x0FFF, shortWays[regs[0] >>
28], update );
push( T, T, T, F, F, regs[1] & 0xFFF, shortWays[regs[1] >> 12 &
0xF], update );
push( T, T, F, T, F, regs[0] & 0xFFF, shortWays[regs[0] >> 12 &
0xF], update );
if( has1GPages() && maxExtCpuid >= 0x80000019u )
cpuid( regs, 0x80000019u, 0 ),
push( F, F, F, F, T, regs[0] >> 16 & 0xFFF, shortWays[regs[0]
>> 28], update ),
push( F, T, F, F, T, regs[0] & 0xFFF, shortWays[regs[1] >> 12
& 0xF], update ),
push( T, F, F, F, T, regs[1] >> 16 & 0xFFF, shortWays[regs[0]
>> 28], update ),
push( T, T, F, F, T, regs[1] & 0xFFF, shortWays[regs[1] >> 12
& 0xF], update );
return nTLBs;
};
tlbs.reserve( gatherTLBs( F ) );
gatherTLBs( T );

then push() just looks like an ordinary local function.

What could be significantly improved are all those bitfield ops. Ideally
you would use named bitfields within what is presumably a 32-bit
unsigned value, instead of all those mysterious shifts and masks.

Those 0xFFF masks mixed with 16-bit shifts look suspicious until you
realise these are 12+4-bit fields in each half of a 32-bit value.

Here even a simple GETBITS macro would improve both readability and
confidence that the code is correct.

I don't do named bitfields outside of a struct [in my languages], but at
least I can manage this:

macro F1 = 0..11
macro F2 = 12..15
macro F3 = 16..27
macro F4 = 28..31

push(F,F,F,F,T, regs[0].[F3], shortways[regs[1].F4)

Better if I knew what those fields were for then I could give proper names.

So, it looks like your emphasis is different aspects: those elusive
lambdas (which doesn't help readability at all, unless it would be even
worse without them), rather than doing something about basic readability.

I'd also have aliases for regs[0] and regs[1], such as R0 and R1 (after
all you write assembly using R0 not REGS[0]).

Those first 5 Bool parameters for push also look like they are ripe for
conversion to a single flag parameter containing 5 single-bit fields
(Just Or-ing named bit-masks would be better.)

Remember your original looked like this:

push( false, false, true, false, false, ...

What do each of these signify? At least, if using multiple parameters,
use keyword parameters combined with a default value, such as false,
then this example can become:

push(..., FlagA:true)

(Keyword parameters go after positional ones.) Again I don't know what
these mean so can't give a more useful name.

(Does C++ have keyword parameters? It looks like it doesn't.)

Am 16.12.2021 um 15:16 schrieb Bart:

> Which bit is the lambda? If I create a more compact version so that I
> can see the whole thing more easily:

There is no way to have it more readable than with the lambdas.

> then push() just looks like an ordinary local function.

push() saves a lot of redundant code and it does make sense only locally
within that function - a perfect case for a lambda.

> What could be significantly improved are all those bitfield ops.
> Ideally you would use named bitfields within what is presumably
> a 32-bit unsigned value, instead of all those mysterious shifts
> and masks.

I get the values from CPUID and it would make no sense to move that
to a bitfield'ed structure that because this should compile with
three compilers (MSVC, clang, g++) and they behave not absolutely
the same with bitfields.

> Those 0xFFF masks mixed with 16-bit shifts look suspicious until you
> realise these are 12+4-bit fields in each half of a 32-bit value.

What I do is correct, look at the corresponding CPUID-documentation.

> Here even a simple GETBITS macro would improve both readability and
> confidence that the code is correct.
>

Macros are a no-go since they're global and often not debuggable
(depending on the IDE).

> So, it looks like your emphasis is different aspects: those elusive
> lambdas (which doesn't help readability at all, unless it would be even
> worse without them), rather than doing something about basic readability.

Of course the lambdas make the code more readable because they save
a huge amount of redundant code.

On 16/12/2021 14:49, Bonita Montero wrote:
> Am 16.12.2021 um 15:16 schrieb Bart:
>
>> Which bit is the lambda? If I create a more compact version so that I
>> can see the whole thing more easily:
>
> There is no way to have it more readable than with the lambdas.
>
>> then push() just looks like an ordinary local function.
>
> push() saves a lot of redundant code and it does make sense only locally
> within that function - a perfect case for a lambda.

So which bit /is/ the lambda?!

>
>> What could be significantly improved are all those bitfield ops.
>> Ideally you would use named bitfields within what is presumably
>> a 32-bit  unsigned value, instead of all those mysterious shifts
>> and masks.
>
> I get the values from CPUID and it would make no sense to move that
> to a bitfield'ed structure that because this should compile with
> three compilers (MSVC, clang, g++) and they behave not absolutely
> the same with bitfields.

The docs for CPUID will be full of named bitfields; surely there is some
way of naming those values instead of hard-coding meaningless numbers
for shifts and masks.

>> Those 0xFFF masks mixed with 16-bit shifts look suspicious until you
>> realise these are 12+4-bit fields in each half of a 32-bit value.
>
> What I do is correct, look at the corresponding CPUID-documentation.
>
>> Here even a simple GETBITS macro would improve both readability and
>> confidence that the code is correct.

> Macros are a no-go since they're global and often not debuggable
> (depending on the IDE).

So, inlined functions, templates ... does C++ really have no better way
of isolating a specific bitfield in A than using:

(A>>x) & y

where x is the start bit, and y is so many 1-bits depending on the
field's width?

Here's a much better approach using only C features:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/cpuid.h

>> So, it looks like your emphasis is different aspects: those elusive
>> lambdas (which doesn't help readability at all, unless it would be
>> even worse without them), rather than doing something about basic
>> readability.
>
> Of course the lambdas make the code more readable because they save
> a huge amount of redundant code.

How many more lines would this example have been without lambdas?

Because I'm sorry but I just can't see it. All I can see is that it uses
CPUID to extract info into a bunch of registers. Then you extract some
fields from those into an array of values.

Given a way to call CPUID, you don't need any special language features
for what seems a rather trivial task.

It's also not clear whether this is real or made-up code, since the
information returned using 0x80000006 doesn't correspond with what
you're trying to extract. But then we don't know the mapping of regs[]
to rcx etc, nor whether cpuid() is a real thing, as I had trouble
finding some info on it.

BTW here's how I use cpuid [not C]:

static [16]char id

assem
mov eax, 0
cpuid
mov [id], ebx
mov [id+4], edx
mov [id+8], ecx
end

println "Processor ID =",id

This displays:

Processor ID = AuthenticAMD

On 16/12/2021 15:16, Bart wrote:
> On 16/12/2021 06:54, Bonita Montero wrote:
>> Here's another good example of using long lambdas:
>>
>>          auto gatherTLBs = [&]( bool update ) -> size_t
>>          {
>>              size_t nTLBs = 0;
>>              auto push = [&]( bool l2, bool code, bool _4k, bool
>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>              {

<snip>

>
> So, it looks like your emphasis is different aspects: those elusive
> lambdas (which doesn't help readability at all, unless it would be even
> worse without them), rather than doing something about basic readability.

The lambdas here are nothing more nor less than function-local
functions. Neither C nor C++ has support for local functions (unlike
Pascal, Ada, and many other languages - including gcc extended C).
Lambdas can certainly be convenient for that, and are safer, easier and
better scoped than using macros.

(Readability is in the eye of the beholder, and I'd rather not comment
here. I am also not commenting on the code itself, or how it could have
been written.)

>
> Those first 5 Bool parameters for push also look like they are ripe for
> conversion to a single flag parameter containing 5 single-bit fields
> (Just Or-ing named bit-masks would be better.)
>
> Remember your original looked like this:
>
>     push( false, false, true, false, false, ...
>
> What do each of these signify? At least, if using multiple parameters,
> use keyword parameters combined with a default value, such as false,
> then this example can become:
>
>     push(..., FlagA:true)
>
> (Keyword parameters go after positional ones.) Again I don't know what
> these mean so can't give a more useful name.
>
> (Does C++ have keyword parameters? It looks like it doesn't.)
>
>

No, C++ does not have keyword parameters. It is something that comes up
again and again in propositions, requests and suggestions, and hopefully
it will be included eventually. But there are large number of
possibilities and choices involved that make it surprisingly difficult
to pin down exactly how keyword parameters could be added to the language.

But C++ /does/ have several alternatives to a long list of booleans like
this. The simplest would be:

enum class FlagA { True, False };
enum class FlagB { True, False };

void foo(FlagA a, FlagB b);

void bar(void) {
foo(FlagA::True, FlagB::False);
}

You can't get this wrong and call "foo(FlagB::True, FlagA::False)" - the
compiler would spot the error. Strong types like this for parameters
can help if you have a long parameter list.

Bart <bc@freeuk.com> writes:

> On 16/12/2021 14:49, Bonita Montero wrote:
>> Am 16.12.2021 um 15:16 schrieb Bart:
>>
>>> Which bit is the lambda? If I create a more compact version so that I can see the whole thing more easily:
>> There is no way to have it more readable than with the lambdas.
>>
>>> then push() just looks like an ordinary local function.
>> push() saves a lot of redundant code and it does make sense only locally
>> within that function - a perfect case for a lambda.
>
> So which bit /is/ the lambda?!

The bit that starts [&], followed by a function header (with C++'s new
-> return_type syntax) and a block. I.e. most of the first line and all
but two lines of the rest of the posted code..

--
Ben.

On 16/12/2021 16:24, David Brown wrote:
> On 16/12/2021 15:16, Bart wrote:
>> On 16/12/2021 06:54, Bonita Montero wrote:
>>> Here's another good example of using long lambdas:
>>>
>>>          auto gatherTLBs = [&]( bool update ) -> size_t
>>>          {
>>>              size_t nTLBs = 0;
>>>              auto push = [&]( bool l2, bool code, bool _4k, bool
>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>>              {
>
> <snip>
>
>>
>> So, it looks like your emphasis is different aspects: those elusive
>> lambdas (which doesn't help readability at all, unless it would be even
>> worse without them), rather than doing something about basic readability.
>
> The lambdas here are nothing more nor less than function-local
> functions. Neither C nor C++ has support for local functions (unlike
> Pascal, Ada, and many other languages - including gcc extended C).
> Lambdas can certainly be convenient for that, and are safer, easier and
> better scoped than using macros.

So the lambda here is the local 'function' that includes that '[&]`
(according to BB)?

That's not what I'd think of as a 'lambda', which would be a function
(parameter-spec and body) embedded in an expression - code to be
evaluated later not as encountered.

I'm surprised that even gnu C++ doesn't have local functions (or does it?).

In that case a more suitable and more useful feature would have been
local functions.

(Which I used to implemented, but I kept them simple to avoid problems
with accessing or capturing surrounding variables: accesses to
stack-allocated variables of the enclosing function(s) were banned; but
everything else was accessible.

To implement BM's example, 'update' and 'nTLBs' would need to be static,
or copied to a static variable.

I no longer have them because they were never used, and they caused
problems when an 'end' was left out, as that was only detected at the
end of the file rather than at the start of the next function, which was
interpreted as nested.)