[fpc-devel] threadvar implementation

[Hans-Peter Diettrich]

Michael Schnell schrieb:

>> Only FS and GS can add an non-zero offset, to the *offset* given in 
>> the instruction. The sum of both is the flat "address" (effectively 
>> another offset), that can be stored in a pointer variable. In 32/64 
>> bit flat memory models all pointers are "near", i.e. they don't 
>> include an segment selector, and a zero-based segment is implied (DS...).
> The segment ("Selector") content is not an offset (any more), but it 
> uses a table of offsets that is managed by the OS.

The segment selector refers to an segment descriptor, to which above 
segment-base restrictions apply in the flat memory model.

> The user land 
> software never sees this, so the pointer can't hold a "flat address", 
> but when using a pointer some selector register needs to be used. if 
> none is given, this is DS. As Pascal does not provide means to define a 
> pointer type as being a pointer to a threadvar, it _always_ uses DS and 
> thus a pointer to a threadvar is not possible with X86/32-Linux. Of 
> course this is not true with a flat memory model. But is it possible to 
> do "flat" software with FP on X86/32 Linux (or Windows) ?

We are doing "flat" software all the time. The last use of segmented 
pointers dates back to Win3.1, with near and far pointers. The IA32 
architecture restricted the total address space to 4GB (32 bit), with 
rare exceptions for server-type CPUs. Otherwise we could have used 2^16 
different segments of 4GB each, in 32 bit applications. Since that time 
segment registers and selectors can serve only memory protection 
purposes, but can not extend the address space beyond the hard 4GB limit.

DoDi