On Mar 14, 7:42 pm, Bill Hart <goodwillh...@googlemail.com> 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.
>
> 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
I have built, tested and committed the revised Core2 assembler for
mpn_add_n and mpn_sub_n on Windows.
As this assembler also provides the *_nc function calls I have added
these as well on Windows.
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
-~----------~----~----~----~------~----~------~--~---
