On Thursday 20 May 2010 10:13:54 Cactus wrote: > On May 20, 2:58 am, Jason Moxham <[email protected]> wrote: > > On Thursday 20 May 2010 02:11:11 Bill Hart wrote: > > > There's a new Opteron on the block. family 16 model 8. It's an Opteron > > > 8439 SE. We don't have it in cpuid.c yet. > > > > Looks like another K102 , doesn't look like any differences for us , > > although we dont know until we test it. > > By the way the difference between what we call the K102 and the K10 , is > > the "same" as the difference between early K8 and late K8's , a slight > > difference in L1-data cache and store forwarding , which does effect some > > functions eg copy,addadd,lshiftcom , some more than others > > > > > Also we currently have a symbol in the library, mpn_sqr_n and a > > > #define in mpir.h to rename it mpn_sqr in line with gmp. But that > > > isn't sufficient. It breaks gcc on machines where gcc has been built > > > with dynamic libs. On the face of it this shouldn't affect anyone, but > > > in fact it will affect lots of people. The only solution I see is to > > > rename the library symbol. > > > > we can just export both names , so we are compatible with the new gmp AND > > the old > > > > > Also, GMP defines mpn_copyi and mpn_copyd. On generic x86_64 machines, > > > we don't seem to have any assembly for this. There's no fallback > > > generic C symbol in the lib. > > > > we can the fallback C code that a fat build uses , with the new K102 > > cpuid above there is no current generic x86_64 cpu :) > > GMP has copyi.c and copyd.c in its mpn\generic directory to provide > these symbols so I have added code from our x86_64 subdirectory to our > mpn\generic subdirectory. > > As far as I can see, this is not x86_64 specific and should hence work > on other architectures. But I would appreciate it if others could > check on this. > > I have added this to the generic C Windows builds but I have NOT added > it to any of the other builds so someone needs to do this. > > I have NOT done anything about mpn_sqr and mpn_sqr_n as I want to be > sure about what is needed. > > Does the following work? > > 1. The lines in mpir.h: > > #define mpn_sqr_n __MPN(sqr_n) > #define mpn_sqr __MPN(sqr_n) > __GMP_DECLSPEC void mpn_sqr_n __GMP_PROTO ((mp_ptr, mp_srcptr, > mp_size_t)); > > are changed to: > > #define mpn_sqr_n __MPN(sqr_n) > __GMP_DECLSPEC void mpn_sqr_n __GMP_PROTO ((mp_ptr, mp_srcptr, > mp_size_t)); > #define mpn_sqr __MPN(sqr) > __GMP_DECLSPEC void mpn_sqr __GMP_PROTO ((mp_ptr, mp_srcptr, > mp_size_t)); > > 2. In mpn\mul_n.c, after the subroutine: > > void > mpn_sqr_n (mp_ptr p, mp_srcptr a, mp_size_t n) > > add: > > void mpn_sqr = mpn_sqr_n; > > Does this work or am I screwed up? >
I would of thought so , but this has to work with libtool on all the current systems. I've tried looking in libtool to see how to do this but I couldn't find anything , we really want something thats standard , otherwise it will just break some system we havent tested on. It should be pretty easy , it's just a symbol that the library exports , but I'm not sure what happens if it needs to be relocated . Perhaps just fallback to using two identical functions , most programs will use one form or the other and not both . In a static lib we just waste a bit disk space , and in a shared lib it may not get mapped into the address space , or if it is then as it is not run it wont pollute the cache. > I'll do this if we agree here that this is the right solution (and > works!). > > Brian > > REMINDER: add mpn\generic\copyi.c and mpn\generic\copyd.c to the Linux > builds -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
