Re: [fpc-devel] threadvar implementation

Michael Schnell : > In fact I still don't know how the compiler should > construct a pointer to a threadvar in Linux. pthread_getspecific() It returns a pointer to it (well, to the block of associated memory, so maybe adding an offset would be required if more than just one variable is stored

Re: [fpc-devel] threadvar implementation

Michael Van Canneyt schrieb: How can a C compiler be more efficient, if the threadvar concept does not exist in C ? On posix platforms, you must use a series of thread calls to get to your 'thread-local' variable. When accessing a thread variable, FPC uses the same series of calls as one would

Re: [fpc-devel] threadvar implementation

OK all points taken. The pthread-library is used to manage the pointers to the base of the threadvar block. (Same of course does use the GS: stuff on Linux-X86/32 to manage it's own thread specific storage.) Besides the performance argument, the original argument that triggered the discussi

Re: [fpc-devel] threadvar implementation

On 06 Aug 2010, at 11:24, Michael Van Canneyt wrote: How can a C compiler be more efficient, if the threadvar concept does not exist in C ? Most C compilers nowadays have extensions to support threadvars using special keywords. Jonas ___ fpc

Re: [fpc-devel] threadvar implementation

On 06 Aug 2010, at 09:51, Michael Schnell wrote: On 08/06/2010 12:31 AM, Jonas Maebe wrote: (but keep in mind that the only reason that intialising/finalising threads not started via the FPC rtl now works under Unix is exactly because every threadvar access requires a call into a helper r

Re: [fpc-devel] threadvar implementation

On Fri, 6 Aug 2010, Michael Schnell wrote: On 08/06/2010 12:31 AM, Jonas Maebe wrote: (but keep in mind that the only reason that intialising/finalising threads not started via the FPC rtl now works under Unix is exactly because every threadvar access requires a call into a helper routine).

Re: [fpc-devel] threadvar implementation

On 08/06/2010 12:31 AM, Jonas Maebe wrote: (but keep in mind that the only reason that intialising/finalising threads not started via the FPC rtl now works under Unix is exactly because every threadvar access requires a call into a helper routine). Of course this is why I started the thread. Th

Re: [fpc-devel] threadvar implementation

On 05 Aug 2010, at 21:36, Hans-Peter Diettrich wrote: > Michael Schnell schrieb: > >>> FS/GS for non-zerobased segments, all others are zero-based. >> I have no idea what you mean by "zerobased". > > Then you missed fundamental 32/64 bit hardware and software principles :-( > > Please read and

Re: [fpc-devel] threadvar implementation

Michael Schnell schrieb: FS/GS for non-zerobased segments, all others are zero-based. I have no idea what you mean by "zerobased". Then you missed fundamental 32/64 bit hardware and software principles :-( Please read and understand the available documentation, my preceding posts, and ask f

Re: [fpc-devel] threadvar implementation

Michael Schnell : > 2) ES: in my tests I modified ES in ASM code in a Delphi program and > caused it to crash by this, So the Delphi compiler seems to use it (for > whatever purpose) No surprise, in any sane environment DS should be equal to ES. Most notorious instruction requiring that would

Re: [fpc-devel] threadvar implementation

Michael Schnell : > > 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 > v

Re: [fpc-devel] threadvar implementation

On 08/05/2010 11:19 AM, Hans-Peter Diettrich wrote: Please accept that no more than 3 different segments are in use nowadays. This is not true. 1) FS: as discussed in this thread, Windows uses FS to address the thread management block 2) ES: in my tests I modified ES in ASM code in a Delph

Re: [fpc-devel] threadvar implementation

On 08/05/2010 11:19 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: See http://flint.cs.yale.edu/cs422/doc/24547212.pdf page 3-7 The "logical address" is 24 bits: 16 bits "Segment Selector" and 32 bits "Offset". Please be a bit more precise with your bitcounts. Sorry for the typo

Re: [fpc-devel] threadvar implementation

On 08/05/2010 11:09 AM, Hans-Peter Diettrich wrote: I had thought that this has been fixed on newer architectures, that use the flat model only. This can't easily be "fixed" by hardware, how to express that LEA should convert e.g. a DS-based offset into a FS based one or the other way round,

Re: [fpc-devel] threadvar implementation

Michael Schnell schrieb: OK I was wrong by two bits. See http://flint.cs.yale.edu/cs422/doc/24547212.pdf page 3-7 The "logical address" is 24 bits: 16 bits "Segment Selector" and 32 bits "Offset". Please be a bit more precise with your bitcounts. The Selector is used to take one of up to

Re: [fpc-devel] threadvar implementation

Michael Schnell schrieb: IMHO, if the compiler should issue an error message if yo9u give a segment register with LEA, as the result obviously is erroneous. Maybe other compilers in fact do this. I only tested Turbo Delphi. I had thought that this has been fixed on newer architectures, that u

Re: [fpc-devel] threadvar implementation

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

Re: [fpc-devel] threadvar implementation

On 08/04/2010 09:19 PM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: Look at the document I mentioned: a "linear address" is 48 bits, while a pointer is only 32 bits (the "Offset") . Read section 3.3 ff. and 3.8. Linear addresses are always 32 bit, and only a few server-type CPUs h

Re: [fpc-devel] threadvar implementation

OK I was wrong by two bits. See http://flint.cs.yale.edu/cs422/doc/24547212.pdf page 3-7 The "logical address" is 24 bits: 16 bits "Segment Selector" and 32 bits "Offset". Obviously in an instruction, usually the "Segment Selector" is taken from one of the six Segment registers while the "Off

Re: [fpc-devel] threadvar implementation

On 08/04/2010 10:29 PM, "Vinzent Höfler" wrote: |"The source operand is a memory address (offset part)" ^^^ Says that only the offset is used. OK, it says the offset part is _specified_. But the text describes the LEA instruction ("8D") itsel

Re: [fpc-devel] threadvar implementation

Michael Schnell : > I fail to understand what LEA is supposed to do if a (single) segment > register is given :(. Ignoring it, because it is not part of the "effective address" which it is supposed to calculate?

Re: [fpc-devel] threadvar implementation

Von: Michael Schnell : > As Pascal (other than C) does not provide a means to define that a > pointer type is a pointer to a threadvar rather than to a normal var, > Pascal alway uses DS to access any variable. JFTR, plain vanilla C (i.e. ISO C99) does not even have a notion of a "thread varia

Re: [fpc-devel] threadvar implementation

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

Re: [fpc-devel] threadvar implementation

On 08/04/2010 03:57 AM, Hans-Peter Diettrich wrote: Getting the linear address of a threadvar depends on the OS/FPC implementation. Of course the compilker needs to adhere to what the OS provides. As already said multiple times, Win32 for each thread provides a block of user space memory t

Re: [fpc-devel] threadvar implementation

On 08/03/2010 01:30 PM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: Regarding the hardware and without rewriting or switching the selector table, a user land program could access 64K different (potentially non-overlapping) address spaces (each 4 GB size) using a selector register such

Re: [fpc-devel] threadvar implementation

On 08/03/2010 01:37 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: You only have to determine the flat address, before storing it in the pointer variable - @MyThreadvar? How do you think this is possible ? How to you think it's possible in FPC to define a pointer that does not use D

Re: [fpc-devel] threadvar implementation

On 08/03/2010 01:30 AM, Hans-Peter Diettrich wrote: We are doing "flat" software all the time. The last use of segmented pointers dates back to Win3.1, with near and far pointers. It was you who introduced the flat vs segmented paradigm in this discussion. :) Nonetheless, we _always_ do use

Re: [fpc-devel] threadvar implementation

Michael Schnell schrieb: You only have to determine the flat address, before storing it in the pointer variable - @MyThreadvar? How do you think this is possible ? How to you think it's possible in FPC to define a pointer that does not use DS to access the memory location ? No need to do so.

Re: [fpc-devel] threadvar implementation

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

Re: [fpc-devel] threadvar implementation

On 07/30/2010 08:01 PM, Hans-Peter Diettrich wrote: 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

Re: [fpc-devel] threadvar implementation

On 07/30/2010 08:01 PM, Hans-Peter Diettrich wrote: The only question is, whether you want the (absolute, flat) address of the threadvar of an *specific* thread, or the address of the threadvar in the *current* thread. Since the current thread can change, the offset of the threadvar record w

Re: [fpc-devel] threadvar implementation

On 07/30/2010 08:01 PM, Hans-Peter Diettrich wrote: You only have to determine the flat address, before storing it in the pointer variable - @MyThreadvar? How do you think this is possible ? How to you think it's possible in FPC to define a pointer that does not use DS to access the memory lo

Re: [fpc-devel] threadvar implementation

Michael Schnell schrieb: What makes you think that this is different from x86? With X86/32 Linux, the "application"address of a threadvar Please distinguish: Segmented or Flat address? Only FS and GS can add an non-zero offset, to the *offset* given in the instruction. The sum of both is th

Re: [fpc-devel] threadvar implementation

On 07/29/2010 09:41 PM, Hans-Peter Diettrich wrote: What makes you think that this is different from x86? With X86/32 Linux, the "application"address of a threadvar in the ASM instruction is the same for all threads. The ASM instruction is done with a "GS:" prefix, thus instead of the DS sect

Re: [fpc-devel] threadvar implementation

Michael Schnell schrieb: I suppose with this paradigm, pointers to threadvars should work (other than with X86/32-Linux), as the threadvars - other than with X86 - simply have have different effective user space addresses What makes you think that this is different from x86? DoDi __

Re: [fpc-devel] threadvar implementation

FWIW: I checked gcc for the NIOS processor. Same has 32 general purpose registers (similar to ARM) Here +offset is used to access any global (and static) variables, while +offset is used to access any threadvars. Obviously the OS just sees that these registers (like all others) are preemptio

Re: [fpc-devel] threadvar implementation

Ranting on I did a small testing program using FPC on X86/32 Linux and found that GS stays the same with multiple threads (always $0033). So seemingly - just like with Windows (Linux using GS instead of FS) - it's not (as I supposed) that the GS value is a per-Thread constant, but the sel

Re: [fpc-devel] threadvar implementation

26.07.2010 13:04, Michael Schnell: On 07/24/2010 06:55 PM, Nikolai Zhubr wrote: I think only FS selector (and/or descriptor) varies across threads. Seemingly not the selector value (the FS content seems to stay constant among the threads), but the table entry it selects. You are right. Just

Re: [fpc-devel] threadvar implementation

FPC uses the same code with Win32 and with Linux X86/32. It does an indirect call to some external function. So this supposedly is less efficient than Delphi, GnuC or M$ C. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lis

Re: [fpc-devel] threadvar implementation

On 07/26/2010 02:51 PM, Sergei Gorelkin wrote: Michael Schnell wrote: ... This is essentially the same code as with Delphi. Supposedly as with Delphi [__tls_index (417328h) ] is always 0 with normal applications. (no idea what this is useful for) The TLS index is allocated by a call to TlsA

Re: [fpc-devel] threadvar implementation

Michael Schnell wrote: ... This is essentially the same code as with Delphi. Supposedly as with Delphi [__tls_index (417328h) ] is always 0 with normal applications. (no idea what this is useful for) The TLS index is allocated by a call to TlsAlloc at application startup. It will be zero for

Re: [fpc-devel] threadvar implementation

M$ C on Win32 (X86/32), using Visual Studio. declspec(thread) int ithread; ithread = 1; results in mov eax, dword ptr [__tls_index (417328h) ] mov ecx, dword ptr fs:[2Ch] mov edx, dword ptr [ecx,+eax*4] mov dword pth[edx+104h],1 This is essentially the same code as with Delphi. Supp

[fpc-devel] threadvar implementation

As recommended starting a new message thread Reverse engineering: threadvar ithread: integer; ithread := 1; or in "C": __thread ithread int: ithread = 1; Delphi, Win32 on X86/32 (stripping off additional offsets that seemingly are always 0 in normal applications): mov edx, FS: $2c mov