On Saturday 14 March 2009 19:42:33 Bill Hart wrote: > OK, can you try autotools and commit again. I went back to revision > 1730 and made the changes again, this time hopefully without breaking > everything else. >
done > Really odd it didn't tell me my revision was out of date. It usually > does if commits cross in the aether. > Mine wont let me commit unless I'm up to date > Bill. > > 2009/3/14 Bill Hart <goodwillh...@googlemail.com>: > > Oh dear, I think I didn't. I'll back it out and try again. > > > > Bill. > > > > 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>: > >> On Saturday 14 March 2009 19:14:50 Bill Hart wrote: > >>> That's an excellent solution. Now we just need to fix linux so that it > >>> still works on these systems. Oh joy! > >>> > >>> Bill. > >>> > >>> 2009/3/14 Cactus <rieman...@googlemail.com>: > >>> > On Mar 14, 7:03 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > >>> >> On Saturday 14 March 2009 18:35:32 Bill Hart wrote: > >>> >> > OK, found the problem. Nocona now builds with core2 code. Can you > >>> >> > autoconf this and commit. > >> > >> did you use the right configure.in , we seem to have lost some stuff eg > >> GMPLINK > >> > >>> >> I can install my old autotools on another machine, in a few hours. > >>> >> The new autotools require ylwrap , which I added with > >>> >> automake --add-missing > >>> >> ylwrap is used for parralel makes (which I certainly do) > >>> >> It's put it as a symbolic link though , I could copy the file itself > >>> >> > >>> >> commited anyway > >>> >> > >>> >> > So now we need to exclude those broken models after all. :-) > >>> >> > > >>> >> > No need for a full round of testing. We only need to check that > >>> >> > configure still works on all the machines we've tested for and > >>> >> > just randomly test a few full builds. > >>> >> > > >>> >> > Bill. > >>> >> > > >>> >> > 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>: > >>> >> > > On Saturday 14 March 2009 18:13:00 Bill Hart wrote: > >>> >> > >> OK, but I'm still unclear why it doesn't pick up the files in > >>> >> > >> the core2 directory. That is what it should do based on the > >>> >> > >> code that is there. This means noconas are giving a generic C > >>> >> > >> build, which I am sure Gonzalo would have complained about by > >>> >> > >> now if it was the case, because he has a nocona. > >>> >> > > > >>> >> > > Perhaps he uses fat build? , which would think its a core2 > >>> >> > > > >>> >> > > There some references missing in configure.in , and a shed load > >>> >> > > of inconsistencies . I can fix but it means another round of > >>> >> > > testing > >>> >> > > > >>> >> > >> Bill. > >>> >> > >> > >>> >> > >> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>: > >>> >> > >> > On Saturday 14 March 2009 18:07:59 Bill Hart wrote: > >>> >> > >> >> I get: > >>> >> > >> >> > >>> >> > >> >> wbh...@sage:~/mpir-test$ ./configure > >>> >> > >> >> --build=nocona-unknown-gnu-linux checking build system > >>> >> > >> >> type... Invalid configuration > >>> >> > >> >> `nocona-unknown-gnu-linux': machine `nocona-unknown-gnu' not > >>> >> > >> >> recognized > >>> >> > >> >> configure: error: /bin/bash ./config.sub > >>> >> > >> >> nocona-unknown-gnu-linux failed > >>> >> > >> >> > >>> >> > >> >> I think config.sub is broken. > >>> >> > >> > > >>> >> > >> > whoops linux-gnu not gnu-linux > >>> >> > >> > > >>> >> > >> >> Bill. > >>> >> > >> >> > >>> >> > >> >> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>: > >>> >> > >> >> > On Saturday 14 March 2009 17:59:00 Bill Hart wrote: > >>> >> > >> >> >> Are you sure about that: > >>> >> > >> >> >> > >>> >> > >> >> >> case $host in > >>> >> > >> >> >> x86_64-*-* | i786-*-*) > >>> >> > >> >> >> path_64="x86_64/amd64 x86_64" ;; > >>> >> > >> >> >> k10-*-*) > >>> >> > >> >> >> path_64="x86_64/amd64/k10 x86_64/amd64 > >>> >> > >> >> >> x86_64" ;; nocona-*-* | core2-*-*) > >>> >> > >> >> >> <<------------------------------------- > >>> >> > >> >> >> path_64="x86_64/core2 x86_64" ;; > >>> >> > >> >> >> <<------------------------------------- > >>> >> > >> >> >> esac > >>> >> > >> >> >> > >>> >> > >> >> >> Seems to use the core2 code. > >>> >> > >> >> > > >>> >> > >> >> > try with ./configure --build=nocona-unknown-gmu-linux and > >>> >> > >> >> > you get C and done on a real Pentium D as well > >>> >> > >> >> > > >>> >> > >> >> >> Bill. > >>> >> > >> >> >> > >>> >> > >> >> >> 2009/3/14 Jason Moxham <ja...@njkfrudils.plus.com>: > >>> >> > >> >> >> > On Saturday 14 March 2009 17:41:58 Jason Moxham wrote: > >>> >> > >> >> >> >> Early Intel CPUs with Intel 64 lacked LAHF and SAHF > >>> >> > >> >> >> >> instructions available in AMD64 until introduction of > >>> >> > >> >> >> >> Pentium 4 G1 step in December 2005. LAHF and SAHF are > >>> >> > >> >> >> >> load and store instructions, respectively, for certain > >>> >> > >> >> >> >> status flags. These instructions are used for > >>> >> > >> >> >> >> virtualization and floating-point condition handling. > >>> >> > >> >> >> >> > >>> >> > >> >> >> >> I'll find out model numbers soon > >>> >> > >> >> >> > > >>> >> > >> >> >> > No need for MPIR-1.0.0 , all 64bit Pentium's default > >>> >> > >> >> >> > to nonoca which leads to a generic C build. > >>> >> > >> >> >> > > >>> >> > >> >> >> >> On Saturday 14 March 2009 17:20:25 Gonzalo Tornaria wrote: > >>> >> > >> >> >> >> > On Sat, Mar 14, 2009 at 1:45 PM, Jason Moxham > >>> >> > >> >> >> >> > <ja...@njkfrudils.plus.com> > >>> >> > >> >> >> >> > >>> >> > >> >> >> >> wrote: > >>> >> > >> >> >> >> > > I pretty sure all core2 cpus have lahf,sahf , it's > >>> >> > >> >> >> >> > > just some Pentium D dont have it . You can test > >>> >> > >> >> >> >> > > the lahf_lm feature bit in cpuid to see if it's > >>> >> > >> >> >> >> > > got it > >>> >> > >> >> >> >> > > >>> >> > >> >> >> >> > Tested in: > >>> >> > >> >> >> >> > > >>> >> > >> >> >> >> > My laptop: model 6 / family 15 (core 2 duo T5300). > >>> >> > >> >> >> >> > My desktop is family 15 / model 6 (pentium D 930). > >>> >> > >> >> >> >> > > >>> >> > >> >> >> >> > The "lahf_lm" feature is present in both according > >>> >> > >> >> >> >> > to /proc/cpuinfo. > >>> >> > >> >> >> >> > > >>> >> > >> >> >> >> > Note that the laptop is "low end" core 2 (in the > >>> >> > >> >> >> >> > sense it has no VT extensions). The pentium D is > >>> >> > >> >> >> >> > "high end" (in the sense it has VT extensions --- > >>> >> > >> >> >> >> > low end would be pentium D 8xx). Maybe that makes a > >>> >> > >> >> >> >> > difference? > >>> >> > >> >> >> >> > > >>> >> > >> >> >> >> > OTOH, the kvm 64 bit virtual cpu (kvm 72) doesn't > >>> >> > >> >> >> >> > seem to know about the "lahf_lm" (meaning, it won't > >>> >> > >> >> >> >> > report it in cpuid, even if the host processor has > >>> >> > >> >> >> >> > it. I assume the instructions would work anyway.) > >>> >> > >> >> >> >> > > >>> >> > >> >> >> >> > Gonzalo- Hide quoted text - > >>> >> > >>> >> - Show quoted text - > >>> > > >>> > I have just tested my GMP assembler code (based on Pierrick Gaudry's > >>> > code) for mpn_add_n and mpn_sub_n in MPIR on Core2 and it achieves > >>> > the same speed as the current code > >>> > > >>> > So I can solve this on Windows without difficulty by simply using > >>> > this code. > >>> > > >>> > It is very mature code so I don't see any problem in using it (I will > >>> > obviously test it). > >>> > > >>> > Brian > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---