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.
Really odd it didn't tell me my revision was out of date. It usually does if commits cross in the aether. 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 -~----------~----~----~----~------~----~------~--~---
