On 07/20/2010 04:11 PM, Hans-Peter Diettrich wrote:
BTW what about GS ? If same is just restored after preemption, this
could be used by the compiler to point to the Threadvar area.
Since it turned out that loading segment registers is very time
consuming on newer (i486+) processors, the memory management was
changed from segmented (16 bit) into paged (32 bit flat). Segment
registers never should be changed by an application,
Not really, The OS needs to set the segment registers, anyway, when
returning to a preempted thread or process, otherwise it needs to be
clearly documented that the user program is not supposed to use them at
all. Assigning some value - e.g.the pointer to the threadvar area - to
e.g. GS would not harm performance-wise.
it should be left to the OS process/thread scheduler and thread-API
calls.
If a register is not predefined by the OS (such as GS on WIN32), I think
the ABI should inform the ASM programmer about how to use it. Simply
stating "all other registers need to be preserved by the callee" would
suffice and answer the original question about if the compiler would
need to safe GS in case an "external" function might trash it.
Moreover of course the ABI should clearly state how an ASM function is
supposed to create threadvars, anyway.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
