[fpc-devel] threadvar implementation

["Vinzent Höfler"]

Michael Schnell <mschnell at lumino.de>:

> > 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.

Well, LEA does not access the memory in question, otherwise more than just #UD could occur. So there's no MMU involved, thus: No descriptors. That's quite clear from the docs, I suppose. If it would access the memory, those nice multiplication tricks and efficient, different length NOPs used for aligning loops wouldn't be possible (because then you would have to make sure that the "address" part in things like "lea esi, [eax + eax*4]" denotes a valid address).

> > 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 
> instruction.

Hmm. An instruction encoding "FS: mov eax, 34h" would probably work the same. What's the processor supposed to do with the prefix anyway?

> > 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.

Yes, I missed that. Still that's not the problem. The problem is where to store the pointer. :D So, in fact, the transformation has to be done each time you access a thread variable.

> So even the wording "the pointer to the threadvar" is 
> ambiguous.

Not after you resolved it to the "DS based location". Then it does in fact point to the very same instance of a thread variable, no matter what thread the access would happen in.

> 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 
> threadvar.
> 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_ 
> thread.

Yes.

> 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.

And - assuming a correct implementation by the compiler - is quite easily resolved by the programmer depending on what he wants. If the pointer is not a thread variable itself, it does point to the very same location (i.e. the thread variable of a specific thread). If it *is* a thread variable, each thread has its own pointer and thus each one points to a different instance:

threadvar
   x  : Integer;
   tp : ^Integer;

var
   gp : ^Integer;

tp := @x; // Points to a thread's specific instance of x.
gp := @x; // Points to a specific thread's instance of x.

Apart from the fact, the it gets really complex when such variables are exchanged between different threads (but then: why do you used thread variables at all?), am I missing something here?


Vinzent.

-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 ¿/mtl.!*
http://portal.gmx.net/de/go/dsl