On Friday 21 May 2010 02:15:00 Jason Moxham wrote: > 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. >
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=/com.ibm.xlcpp8l.doc/language/ref/fn_attrib_alias.htm http://us.generation-nt.com/function-alias-help-11392192.html if the purpose is to be compatible with gmp-5.x.x then we only need the new symbol. > > 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.
