Tuesday, July 18, 2023

Digest for comp.lang.c++@googlegroups.com - 13 updates in 7 topics

gazelle@shell.xmission.com (Kenny McCormack): Jul 18 11:04AM

In article <u942mc$1apqo$2@dont-email.me>,
>He stopped posting in January.
 
Maybe you should go looking for him.
 
--
"Women should not be enlightened or educated in any way. They should be
segregated because they are the cause of unholy erections in holy men.
 
-- Saint Augustine (354-430) --
red floyd <no.spam.here@its.invalid>: Jul 18 09:34AM -0700

On 7/18/2023 4:04 AM, Kenny McCormack wrote:
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> He stopped posting in January.
 
> Maybe you should go looking for him.
 
The correct response to "What happened to Amine?" is, "Who cares?"
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 18 01:31PM -0700

On 7/18/2023 9:34 AM, red floyd wrote:
>>> He stopped posting in January.
 
>> Maybe you should go looking for him.
 
> The correct response to "What happened to Amine?" is, "Who cares?"
 
Actually, Amine had some interesting algorithms. Not sure if he just
read some papers or not...
Tony Oliver <guinness.tony@gmail.com>: Jul 18 03:47PM -0700

On Monday, 17 July 2023 at 19:53:16 UTC+1, Bonita Montero wrote:
> He stopped posting in January.
He posted on 19-Jun-2023 in comp.programming.threads (his private diary thread)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 18 02:00PM -0700

On 7/10/2023 2:13 PM, wij wrote:
 
>> ;^)
 
> Thanks, it looks my class member rule win! (I can provide stronger restriction).
 
> This is one thousand bill [$1000千圓], keep the change.
 
I concur. :^)
Muttley@dastardlyhq.com: Jul 18 02:55PM

On Mon, 17 Jul 2023 20:36:40 +0200
 
>>> I guess you don't.
 
>> Guess I don't what?
 
>IT is just your private desire.
 
Try using chatgpt for your responses in future, it would make more sense
than the 90s irc bot you seem to be using.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 18 01:41PM -0700

On 7/17/2023 12:53 AM, Kalevi Kolttonen wrote:
>>> coolthreads project. Right after that, iirc, Oracle acquired Sun.
 
>> Iirc, it was around 8000 dollars back then.
 
> That was a big prize. Congratulations.
 
It got delivered to my house when I was tired, stayed up late
programming the night before. I heard a knock at the door, and there it
was... my server!
wow.. cool times. cool threads! ;^)
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 18 12:34PM -0700

On Sunday 23 April 2023, Frederick Virchanza Gotham wrote:
> the stack, then later on we can search the
> stack for this UUID and we'll find our data
> right beside it.
 
 
It's taken me 3 months but today I've come up with a legitimate use for this.
 
If you've been following the C++ Standard Proposals mailing list these past few days, I'm trying to come up with a universal header file to ensure elision of move/copy operations with Named Return Value Optimisation.
 
I order to implement this on 64-bit ARM with the aarch64 instruction set, I need to write a function that will:
(1) Move address of return value into 1st parameter
(2) Jump to a location stored in a thread_local variable
 
It turns out that accessing thread_local variables on aarch64 isn't so simple, as there's more than one system for storing them, see how complicated it can be here:
 
http://bambowu.github.io/linux/RelocationAndTheadLocalStorage/
 
Furthermore I want the code to work fine on a microcontroller that doesn't have multithreading support.
 
And so instead of putting the jump address in a thread_local variable, I'll just push it onto the stack beside a known UUID.
 
I knew this would come in handy somewhere.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 18 01:34AM -0700

Over on comp.unix.programmer, Adam Sampson gave me inline assembler that works:
 
__asm(".text\n"
"Invoke:\n"
" mov x1, x8\n"
" adr x9, f\n"
" ldr x9, [x9]\n"
" br x9\n"
);
 
For the sake of posting to this newsgroup, I simplified my problem just a tiny bit. Previously I told you that 'f' was a global variable defined as follows:
 
void (*f)(void);
 
but in actual fact it's:
 
thread_local void (*f)(void);
 
If I change it to thread_local then try to re-compile the inline assembler, I get a linker error:
 
R_AARCH64_ADR_PREL_LO21 used with TLS symbol f
 
Do you know what syntax I use to access the thread_local variable from assembler? Will I need to write a separate function as follows?
 
void (*getf(void))(void)
{
return f;
}
 
and then call that function from my assembler? I'm worried about corrupting the caller-saved registers, because I perform a 'br' rather than a 'blr' (i.e. I perform a jump rather than a function call). I suppose I could push all the caller-saved registers before invoking 'getf' and then pop afterward... which I know how to do on x86_64 but I'm new to all this aarch64 stuff.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Jul 18 03:55AM -0700

On Monday 17 July 2023, Frederick Gotham wrote:
 
> If I change it to thread_local then try to re-compile, I get a linker error:
 
> R_AARCH64_ADR_PREL_LO21 used with TLS symbol f
 
> Do you know what syntax I use to access the thread_local variable from assembler? Will I need to write a separate function as follows?
 
 
In order to try understand how thread_local variables are accessed from aarch64 assembler, I wrote the following dynamic shared library in C:
 
__thread void (*f)(void);
 
void (*g)(void);
 
void Func(void)
{
g = f;
}
 
I compiled this to 'libtest.so" and then used 'objdump' on it to see:
 
<Func>:
Line 01: stp x29, x30, [sp, #-16]!
Line 02: mrs x1, tpidr_el0
Line 03: mov x29, sp
Line 04: adrp x0, 20000 <__cxa_finalize>
Line 05: ldr x2, [x0, #16]
Line 06: add x0, x0, #0x10
Line 07: blr x2
Line 08: adrp x2, 1f000 <__FRAME_END__+0x1e8c8>
Line 09: ldr x2, [x2, #4032]
Line 10: ldr x0, [x1, x0]
Line 11: str x0, [x2]
Line 12: ldp x29, x30, [sp], #16
Line 13: ret
 
Line #2 appears to put the address of "thread local storage" inside the x1 register.
Lines #4-7 at first glance seem to call the function "__cxz_finalize" (which is the one that gets called at the end of a program to invoke all the destructors of global objects)... but really I just think that the number 0x20000 is being used as a base address to apply offsets to.
Lines #7 definitely is calling some function though, I don't know which one.
Lines #8-12, I'm not sure here... but I think they're moving the value of the thread_local variable 'f' into the global variable 'g'.
 
Can anyone please help me understand this? And explore how I would go about writing aarch64 to access a thread_local variable called 'f'?
Lynn McGuire <lynnmcguire5@gmail.com>: Jul 17 07:22PM -0500

On 7/15/2023 6:20 AM, Sam wrote:
> Lynn McGuire writes:
 
>> We use the implicit this a lot.
 
> Congratulations, you win a gold star.
 
Still waiting for the delivery of my gold star !
 
Lynn
wij <wyniijj5@gmail.com>: Jul 17 07:45PM -0700

On Saturday, July 15, 2023 at 5:33:43 AM UTC+8, Lynn McGuire wrote:
> };
 
> We use the implicit this a lot.
 
> Lynn
 
Great, C++23 doubles its own complexity (and, VISIBLE is important!) again.
So the boss knows they are brilliant and work hard, if I understand the feature correctly.
wij <wyniijj5@gmail.com>: Jul 17 07:42PM -0700

On Monday, July 17, 2023 at 5:27:20 AM UTC+8, wij wrote:
 
> "Throw (std?)'exception' and let the caller knows how to deal with it deals with it"
> ... How convenient the "Advanced error handling mechanism" is! LIE, or like olcott,
> he did not know he kept lying all these years.
 
In all, I hope that stdc++ makes such usecase of "Advanced error handling mechanism" clear:
 
int main()
{
try {
fun(0);
}
catch(Exception e) {
// Don't assume the e has anything specific to fun(0)
// fun(0) is not responsible to what is thrown.
}
return 0;
}
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)