[fpc-devel] threadvar implementation

Michael Schnell mschnell at lumino.de
Thu Aug 5 10:36:57 CEST 2010

  On 08/04/2010 09:40 PM, "Vinzent Höfler" wrote:
> JFTR, plain vanilla C (i.e. ISO C99) does not even have a notion of a "thread variable", because it doesn't have threads. So I don't know what C you're referring to here.
GNU C provides the "__thread" keyword to specify threadvars. M$ C 
provides "declspec(thread)" for the same purpose. I did check that this 
work (with M$C on WIN32 and with GNU C on NIOS/Linux) and took a look at 
the code constructed when accessing a threadvar.

I do know that there are GNU C implementations that don't support the 
__thread keyword, so it seems to be "optional".

In fact I did not reverse-engineer how one of these compiler deals with 
pointers to threadvars, but as __thread is a specification to a type and 
C can construct a pointer to any definable type, not doing it the 
correct way would be erroneous.

> No need to. The segment value is not used by LEA. It calculates the "effective address" which basically means the offset.
Yep "basically". :) But with other instructions the same notation and 
description as used for "effective address" with LEA is used to access a 
value in memory and thus the 48 bit "Logical address" (see  Figure 3-5 
in http://flint.cs.yale.edu/cs422/doc/24547212.pdf ). I in fact did 
expect that LEA just works works with "Offsets", but I feel that it is 
not really unambiguously stated in the docs.

> I'm sure you meant "FS prefix". DS doesn't have one AFAIR.
I did not check this

might make some kind of sense :)

> Loading the effective address. Any decent assembler could "optimize" that code into a "mov eax, 34h".
the optimization would be just do kill the obviously unused prefix 
> Or do that beforehand and "simply" store the pointer to the threadvar.

There is no "the threadvar", as the memory location of same is different 
with each thread. So even the wording "the pointer to the threadvar" is 
ambiguous. If the pointer variable itself is a threadvar or a local var 
in a function, it might hold the correct thread specific address of the 

If the pointer variable is static or global, it can be used in one 
thread and hold the address of the thread var specific for _another_ 

So what do we want to accomplish in a certain program ?
This obviously is not a problem of the compiler or the implementation, 
but a more "general" issue.


More information about the fpc-devel mailing list