For the purpose of this discussion, I’m going to assume you are familiar with the x86 32-bit and 64-bit instruction set architectures.<\/p>\n
In Windows on x86, a pointer to per-thread information is kept in the Why do it this way when you could combine it into one?<\/p>\n Access to the per-thread data is abstracted into the helper function One option for optimizing access to per-thread data is to create a custom accessor for each thing you need.<\/p>\n This gets rather unwieldy as the number of fields in the Another option is to teach the compiler’s peephole optimizer that, if compiling in Windows ABI mode, it can fold the instruction sequence, provided the first Furthermore, switching over could end up being worse: The offset field of an absolute selector-relative load is a 32-bit field, whereas the offset when applied to a general-purpose register can be made as small as eight bits. There is typically a penalty for accessing memory through a segment register whose base is not zero.\u00b9 Furthermore, you have to pay for the prefix byte, and are probably taking the processor down an execution path that is not heavily optimized. If you are going to access per-thread data more than once in a function, you may very well have been better off just caching the result in a general-purpose register so you could use the smaller (and probably more efficient) flat addressing mode instead.<\/p>\n Even if all the calculations show that accessing the per-thread data from scratch is better than caching it in a general-purpose register (say, because the x86-32 is so register-starved that freeing up even one register is a big deal), you have to redo the cost\/benefit calculations for the other architectures.<\/p>\n These architectures break down into two categories: Those for which the offset from the TEB register can be folded into the instruction, and those for which it cannot.<\/p>\n For the architectures that don’t support folding, there’s no benefit to the optimization. And fetching the address from scratch is a pessimization on Alpha, since the call to get the address of per-thread data is a system call.<\/p>\n In order to benefit from this optimization on processors where it’s helpful, without hurting the ones where it’s harmful, you may end up having to write two versions of every function: One which gets the per-thread pointer from scratch every time, and one which caches it. The compiler cannot do this transformation for you because it doesn’t know whether the per-thread data can safely be cached: If there is a fiber switch, then the per-thread data cannot be cached since the fiber might be resuming on a different thread!<\/p>\n Given that this optimization may not actually be beneficial, and even if it is, the benefit is slight, and even that slight benefit comes at a cost to other architectures, you’re probably better off not bothering with this micro-optimization and just writing portable code.<\/p>\nfs<\/code> register (for x86-32) or the gs<\/code> register (for x86-64). If you disassemble through the kernel, you’ll see that accesses to the per-thread information usually goes through two steps:<\/p>\n mov eax, dword ptr fs:[0x00000018]\r\n mov eax, dword ptr [eax+n]\r\n<\/pre>\n
mov eax, dword ptr fs:[n]\r\n<\/pre>\n
NtCurrentTeb<\/code><\/a>, and the definition of that function changes based on the processor architecture.<\/p>\n\/\/ x86-32\r\nreturn (struct _TEB *) (ULONG_PTR) __readfsdword (0x18);\r\n\r\n\/\/ x86-64\r\nreturn (struct _TEB *)__readgsqword(FIELD_OFFSET(NT_TIB, Self));\r\n<\/pre>\n
inline DWORD GetLastErrorFromTEB()\r\n{\r\n#if defined(_M_IX86)\r\n return __readfsdword(FIELD_OFFSET(TEB, LastErrorCode));\r\n#elif defined(_M_AMD64)\r\n return __readgsdword(FIELD_OFFSET(TEB, LastErrorCode));\r\n#else\r\n ... other architectures here ...\r\n#endif\r\n}\r\n<\/pre>\nTEB<\/code> increases, since each one needs its own custom accessor. So maybe you abstract it into a macro.<\/p>\n#if defined(_M_IX86)\r\n#define GetDwordFieldFromTEB(Field) \\\r\n __readfsdword(FIELD_OFFSET(TEB, Field))\r\n#define GetPointerFieldFromTEB(Field) \\\r\n __readfsdword(FIELD_OFFSET(TEB, Field))\r\n#elif defined(_M_AMD64)\r\n#define GetDwordFieldFromTEB(Field) \\\r\n __readgsdword(FIELD_OFFSET(TEB, Field))\r\n#define GetPointerFieldFromTEB(Field) \\\r\n __readgsqword(FIELD_OFFSET(TEB, Field))\r\n#else\r\n ... other architectures here ...\r\n#endif\r\n\r\nDWORD GetLastError()\r\n{\r\n return GetDwordFieldFromTEB(LastErrorCode);\r\n}\r\n\r\nPEB GetProcessEnvironmentBlock()\r\n{\r\n return (PEB)GetPointerFieldFromTEB(Peb);\r\n}\r\n<\/pre>\nfs<\/code> access is to exactly the value 0x18<\/code>. This would be a very special compiler optimization that would kick in only for a limited audience. While it’s true that the compiler team has been known to produce custom versions of the compiler for one-off situations<\/a>, the savings for this particular micro-optimization would be, if you’re lucky, a few thousands of instructions. That’s a lot of work to save a few dozen kilobytes.<\/p>\n\/\/ arm\r\nreturn (struct _TEB *)(ULONG_PTR)_MoveFromCoprocessor(CP15_TPIDRURW);\r\n\r\n\/\/ arm64\r\nreturn (struct _TEB *)__getReg(18); \/\/ register x18\r\n\r\n\/\/ alpha\r\nreturn (struct _TEB *)_rdteb(); \/\/ PAL instruction\r\n\r\n\/\/ ia64\r\nreturn (struct _TEB *)_rdtebex(); \/\/ register r13\r\n\r\n\/\/ MIPS\r\nreturn (struct _TEB *)((PCR *)0x7ffff000)->Teb;\r\n\r\n\/\/ PowerPC\r\nreturn (struct _TEB *)__gregister_get(13); \/\/ register r13\r\n<\/pre>\n
\n\n
\n Architecture<\/th>\n Can fold?<\/th>\n Notes<\/th>\n<\/tr>\n \n x86-32<\/td>\n Yes<\/td>\n mov eax, fs:[n]<\/code><\/td>\n<\/tr>\n\n x86-64<\/td>\n Yes<\/td>\n mov rax, gs:[n]<\/code><\/td>\n<\/tr>\n\n arm<\/td>\n No<\/td>\n Cannot use offset load from coprocessor register<\/td>\n<\/tr>\n \n arm64<\/td>\n Yes<\/td>\n ldr x0, [x18, #n]<\/code><\/td>\n<\/tr>\n\n alpha<\/td>\n No<\/td>\n Address returned by dedicated instruction<\/td>\n<\/tr>\n \n ia64<\/td>\n Yes<\/td>\n Can calculate effective address directly from r13<\/td>\n<\/tr>\n \n MIPS<\/td>\n No<\/td>\n No absolute addressing mode<\/td>\n<\/tr>\n \n PowerPC<\/td>\n Yes<\/td>\n lwz r0, n(r13)<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n