[KinoSearch] [kinosearch-commits] r5736 - trunk/perl/buildlib/KinoSearch

[Peter Karman]

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/  .  peter at peknet.com