|
Re^11: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by BrowserUk (Patriarch) on Aug 29, 2012 at 18:31 UTC
|
I'd be amazed if LLVM could determine that the value won't change between calls!
Sorry, but I do not understand this. One thread == one interpreter == one stack. Code cannot call between threads, and threads do not switch stacks (easily).
If the address of the current interpreter was stored in (say, on Intel) the FS or GS register, when the scheduler preempts one thread and loads another, it would restore that register, just as it does for the SP and IP and all the others. Every time a particular thread/interpreter is running, its context would be available in that register; and (on Intel) all the offsets within that context structure would be available as indexed addressing via that segment register.
On other processors, mostly register rich compared to Intel, the same thing could be done.
Basically, the 'reserved' register is loaded with the context when the thread (including the first) is started, and if nothing else is allowed to touch that register -- pretty much guaranteed on Intel -- it value is always available without needing to pass it around to every function.
LLVM might need a custom addition to its code generation routines (for each platform), to support that, but LLVM allows that to be done.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong
| [reply] |
|
|
The Perl stack has nothing to do with the C stack. And a Perl interp has no connection to a particular OS thread, just that it can only be on 1 OS thread at any given time (except when you press Ctrl-C in VC/Mingw Perl, 10% of the time you crash or panic since the interp is running in 2 different threads). A Perl interp can be moved between OS threads whenever and as much as anyone wants aslong as PERL_SET_CONTEXT is called correctly to update the TLS portably. There is no normal way on X86 Windows to have a thread specific global register unfortunately. Changing FS/GS register is quite dangerous since you will crash if you call anything in (kernel/user/gdi)32 and FS/GS isn't the TIB *. A very adventurous compiler might be crazy enough to do things like reuse ESP (I said ESP, not EBP) and FS registers on Windows. That compiler would probably have to have anonymous developers because of all the death threats and malpractice accusations they will get for writing a virus making compiler. Of course a compiler is free to use any calling convention for statics. Perhaps LLVM can be used to create an abstract Perl specific calling convention that is portable to different OSes and CPUs, and on X86 Windows would result in a thread specific global register.
| [reply] |
|
|
Changing FS/GS register is quite dangerous since you will crash if you call anything in (kernel/user/gdi)32 and FS/GS isn't the TIB *.
You're right! I have spent too long living in the x64 world and am forgetting the details of x86.
On x86 it is the ES: segment register that is 'unused'.
On x64, FS: is 'unused'. (GS: points to the TIB/TEB; and ES: (like CS: DS: & SS:) is 'forced to zero'.)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong
| [reply] |
Re^11: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?
by BrowserUk (Patriarch) on Aug 29, 2012 at 19:53 UTC
|
This requires (at least the last time I looked in the linux pthreads library) the current stack pointer to be compared against the stack range allocated to each current thread, to determine which thread we are.
As an aside, I don't understand why the context needs to be passed from function to function to function anyway?
On windows, you allocate a global uint, assign the return from DWORD tlsindex = TlsAlloc() to it at process startup, and then whenever thread needs access to its TLS, it calls TlsSetValue( tlsIndex, pointer ); and struct context p = TlsGetValue( tilsIndex );.
And I read that pthreads has the equivalent pthread_key_create(), pthread_setspecific(), pthread_getspecific() calls which perate in a similar fashion.
So why does context have to be passed around, and reasserted in every routine, even those that (apparently) do not make any ised of it or what it points to?
I really do not understand why the perl context cannot be retrieved from TLS when it is needed, rather than passed around like a baton?
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP Neil Armstrong
| [reply]
[d/l]
[select] |
|
|
I really do not understand why the perl context cannot be retrieved from TLS when it is needed, rather than passed around like a baton?
Because on linux pthreads at least, retrieving a value from TLS is very expensive (using the "match the SP to a thread" trick). Passing an extra parameter is a lot quicker.
As to why they don't reserve a register for it, you'd have to ask them. But I would speculate that it boils down to the fact that you can't assume that all code from all libraries compiled by all the different possible compilers on all the different platforms all know and agree that they're not allowed to touch register X. If this had been agreed on day 1, then maybe; not so much now.
Dave.
| [reply] |
|
|
The perl context is passed around as pTHX and aTHX as a C param. Only legacy/abandoned XS code and the C Lib emulators in Perl call Perl_get_context() nowadays. Not using PERL_NO_GET_CONTEXT for all XS code in the last 10 years is a sin. Then again, most CPAN authors don't care (I'm staring at you Win32:: namespace).
| [reply] |
|
|
The perl context is passed around as pTHX and aTHX as a C param.
That's even worse.
| [reply] |
|
|
|
|
|
|
|
Not using PERL_NO_GET_CONTEXT for all XS code in the last 10 years is a sin. Right, its a sin not to posses secret knowledge -- PERL_NO_GET_CONTEXT site:perldoc.perl.org
Then again, most CPAN authors don't care (I'm staring at you Win32:: namespace). Right, because non-threaded perls are the bees-knees on win32, and PERL_NO_GET_CONTEXT is reported to all these non-caring sharers of code ( PERL_NO_GET_CONTEXT site:rt.cpan.org, )
| [reply] |
|
|
|
|