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. >> >> 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 -~----------~----~----~----~------~----~------~--~---
