[fpc-devel] OO rewrite - technical questions

[Michael Schnell]

  On 07/23/2010 02:06 PM, Hans-Peter Diettrich wrote:
>
> Do you mean segment or general-purpose register(s)?
This depends on the arch. X86 does not really have general-purpose 
registers, while NIOS, ARM MIPS (and supposedly X86/64) has almost only 
general-purpose registers.
> How is that different from WinAPI?
The whole discussion here is that X86/32-WinAPI in fact uses a segment 
register for this purpose but it's nowhere decently documented.
Moreover (bus not a problem) I understand that gnu C on  X86/32 Linux 
uses a segment register as a pointer to the threadvar area, while the 
non-documented WinAPI uses a segment register as a pointer to a 
thread-dedicated structure that again contains a pointer to the 
threadvar area.
> When we consider threads created in a DLL/.so, too, then the platform 
> has to establish such conventions, for the entire app<->library ABI.
Not really. The main executable can create a thread and a function 
called in the thread can internally declare and use a static threadvar. 
So the ABI needs to document how the (ASM) function is supposed to 
access the threadvar it internally defines. As it needs to use a 
register for this, the ABI needs to define that the alee is to use 
exactly this register and (supposedly) that the callee is not supposed 
to modify it when it returns.
>
> How else should it be done, in a practical way? Registers are not a 
> solution, since:
> Assume you have 10 units, each of which declares only one threadvar - 
> then you would have to reserve 10 registers for these threadvars, 
> application-wide!
Sorry but here you are decently wrong.

With most archs all static variables (such as globals and threadvars) 
always are accessed relative to a register. With X86/32 globals and 
statics are allocated relative to DS, with X86/32-Linux, threadvars are 
allocated relative to FS. The archs i know, that don't have segment 
registers use "address"- or "general purpose" registers for this. So  we 
have two "basic data pointers": one for the normal static vars and one 
for the threadvars. Both are safe regarding preemption. The basic 
pointer for normal static vars is initialized at the program start and 
never changed within the application, the pointer to the threadvars is 
initialized when a thread starts and - because it is preemption save 
just like any other register - its never changed when this thread is 
running.

Moreover the point with threadvars is that threads that use the same 
code see different values in the same threadvar. These threads of course 
can't use different registers to access them as the run the same code.

>
> IMO this duplicates the OS overhead (for the thread memory (TLS) 
> implementation), in the application. A single threadvar then would be 
> sufficient for *all* threads, i.e. the one (register) provided for 
> thread-storage by the platform.
See "the point with threadvars...".
>
> Can you give a more concrete example?
See "the point with threadvars...".
>
> I'm not familiar with actual thread programming, so I have no idea 
> about the *usage* of threadvars in concrete code. 
Using threadvars only make sens for multiple threads running the same code.

-Michael