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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
