site_archiver@lists.apple.com Delivered-To: Darwin-dev@lists.apple.com Mail-followup-to: Darwin-dev@lists.apple.com User-agent: Mutt/1.5.6+20040907i Hi. In order to speedup access to thread local variables in the code generated by the mono JIT, I'd like to inline the code sequence directly instead of calling pthread_getspecific (). Of course I know this is risky, since the implementation could change, so I wrote some code to detect what pthread_getspecific() actually does: if the code doesn't do what is expected we fallback to the call to pthread_getspecific(). The interesting thing is that when I read the instructions of the pthread_getspecific implementation (ie the __pthread_getspecific code setup by the kernel), they are mostly 0, just the first instruction is a nop. Dump of assembler code for function pthread_getspecific: 0x90001de0 <pthread_getspecific+0>: li r4,72 0x90001de4 <pthread_getspecific+4>: ba 0xffff82c0 <__pthread_getspecific> Dump of assembler code for function __pthread_getspecific: 0xffff82c0 <__pthread_getspecific+0>: nop 0xffff82c4 <__pthread_getspecific+4>: .long 0x0 0xffff82c8 <__pthread_getspecific+8>: .long 0x0 0xffff82cc <__pthread_getspecific+12>: .long 0x0 [...] It's a surprise that the cpu can execute the code even if it appears as nop/zeroes when read. I tried to mprotect the relevant page, but that returns permission denied: it shouldn't be read-protected though, or I'd get a SEGV reading it. Anyway, for informational purpouses it would be interesting to know why reading the memory area returns odd results. Forcing the code to use the spr register 259 (as should be on the G5 machine) works and gives the expected speedup. On the practical side: anyone has suggestions on how to reliably detect which code sequence to use? Depending just on the processor type is more fragile than actually checking what the code does and we'd have to use the slower function call on Mac OSX... Thanks. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com