[fpc-devel] threadvar implementation

[Michael Schnell]

  On 08/04/2010 12:04 PM, Hans-Peter Diettrich wrote:
> Well, different thread implementations exist for Linux. And the
> threadvar implementation is fully up to the compiler - so that FPC
> could use a Linux threadvar that holds the address of the FPC
> threadvar block - just like implemented for Windows.
OK, the FPC RTL could create a one word sized "thread management block", 
just to hold the DS-notation of the offset of the threadvar block. This 
is other than GNU C in Linux works, but maybe this in fact is a good 
idea as it allows for pointers to threadvars and is faster than the 
current implementation (with any access to a threadvar calling a 
function that I failed to analyze).
> Since all pointers are linear addresses, this is not a problem.
Look at the document I mentioned: a "linear address" is 48 bits, while a 
pointer is only 32 bits (the "Offset") . So with FPC and Delphi always 
DS is used to provide the additional 16 bits, while with C (supposedly) 
GS is used to provide the additional 16 bits in case of a pointer type 
that points to a variable of a type denoted with "__thread".
> Too bad, I had thought that LEA takes into account the segment base :-(
And I assumed it would not compile if a segment is denoted (also :-( 
    :).

If lea would take the segment base into account (a nice idea) it would 
need to know about both the segment to be used as a source as the 
segment that the result is to be used with. Giving multiple segment 
prefixes is not possible. Moreover LEA would need to result in an error 
if the source and/or target segment does not provide the requested address.

Thus LEA without a segment notification assumes source and target 
segment register to be the same, i.e. just handles the 32 Bit "Offset". 
I fail to understand what LEA is supposed to do if a (single) segment 
register is given :(.

Funny stuff..

-Michael