Re^12: Perl 5 Optimizing Compiler, Part 4: LLVM Backend?

[bulk88]

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.

[BrowserUk]

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