Marvin Humphrey wrote on 1/23/10 10:02 PM:
OK, what about your suggestion of scanning cppsymbols? On my custom-compiled
vanilla debugging Perl on CentOS 5.2, I see lots of "i386". So, we could try
this hack: if it says it's i386, tell it "Haha nice try -- use the i486
instruction set at least."
that's right along the line I was thinking. Seems like it is a redhat thing.
I don't know to what extent we can trust $Config{cppsymbols}, though. The
output below from my PowerPC Mac Mini seems highly suspect.
Screw it. I'm giving up.
amen.
The only time that atomic intrinsics get used right now are when adding new
classes to VTable_registry, which is a LockFreeRegistry. That happens
infrequently enough that performance is not a concern and we can fall back to
pthread mutexes on systems where atomics are not made available via system
headers.
yes, that seems right. I noticed the fallback code in there (for Windows?) and
wondered if KS should be able to detect whether atomics are available and Do the
Right Thing.
yogi:perl marvin$ perl -MConfig -le 'print join("\n", split / /,
$Config{cppsymbols})'
__GNUC__=4
__GNUC_MINOR__=0
__LITTLE_ENDIAN__=1
_LP64=1
__LP64__=1
__MACH__=1
__PIC__=1
__STDC__=1
__amd64=1
__amd64__=1
__x86_64=1
__x86_64__=1
yes, those don't help at all because I have the exact same set on my Intel mac.
:/
--
Peter Karman . http://peknet.com/ . [email protected]
