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

[BrowserUk]

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.

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