[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Jason Moxham
On Thursday 19 March 2009 18:43:44 Gonzalo Tornaria wrote: > On Thu, Mar 19, 2009 at 2:35 PM, Jason Moxham wrote: > >> Yes, except config.guess may change it (but it shouldn't, as we > >> discussed before this causes compilation failure, e.g. in a kvm > >> virtual cpu which reports wrong cpuid).

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Gonzalo Tornaria
On Thu, Mar 19, 2009 at 2:35 PM, Jason Moxham wrote: >> Yes, except config.guess may change it (but it shouldn't, as we >> discussed before this causes compilation failure, e.g. in a kvm >> virtual cpu which reports wrong cpuid). >> > > My understanding is that config.guess is to "tweek" the exac

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Gonzalo Tornaria
On Thu, Mar 19, 2009 at 2:32 PM, Jason Moxham wrote: > > On Thursday 19 March 2009 14:31:55 Gonzalo Tornaria wrote: >> On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart > wrote: >> > Wait, how does it currently decide which ABI to use? Does configure >> > decide that aside from what config.guess says.

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Jason Moxham
On Thursday 19 March 2009 14:31:55 Gonzalo Tornaria wrote: > On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart wrote: > > Wait, how does it currently decide which ABI to use? Does configure > > decide that aside from what config.guess says. > > Yes, except config.guess may change it (but it shouldn't,

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Jason Moxham
On Thursday 19 March 2009 14:31:55 Gonzalo Tornaria wrote: > On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart wrote: > > Wait, how does it currently decide which ABI to use? Does configure > > decide that aside from what config.guess says. > > Yes, except config.guess may change it (but it shouldn't,

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Cactus
On Mar 19, 2:37 pm, Bill Hart wrote: > By the way, are you sure it is possible to have lahf and non-lahf > netburst 64 bit chips? > > I thought only very early p4's had this problem, i.e. all 32 bits. Hi Bill This is definitely a problem on some 64-bit processors. Brian --~--~-~

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Bill Hart
By the way, are you sure it is possible to have lahf and non-lahf netburst 64 bit chips? I thought only very early p4's had this problem, i.e. all 32 bits. Bill. 2009/3/19 Jason Moxham : > > > A summary of the new proposed x86_64 directorys > > base directory when all we know is that it is 64bi

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Gonzalo Tornaria
On Wed, Mar 18, 2009 at 10:44 PM, Bill Hart wrote: > Wait, how does it currently decide which ABI to use? Does configure > decide that aside from what config.guess says. Yes, except config.guess may change it (but it shouldn't, as we discussed before this causes compilation failure, e.g. in a kv

[mpir-devel] Re: x86_64 cpuid

2009-03-19 Thread Bill Hart
Aw come on, AMD hasn't done too badly. At least now they have "a portfolio of products suited to a range of needs" or something like that. That's much better than the kx naming system. Anyhow, given the justification you already gave, these names seem good to me. Bill. 2009/3/19 Jason Moxham :

[mpir-devel] Re: x86_64 cpuid

2009-03-18 Thread Jason Moxham
A summary of the new proposed x86_64 directorys base directory when all we know is that it is 64bit x86 and for any code that is common to all x86_64 chips x86_64 For the AMD chips AKA Opteron=K8 Phenom=k10 x86_64/k8 x86_64/k8/k10 For the Intel core2 chips AKA merom=core2-65nm dunnington=pen

[mpir-devel] Re: x86_64 cpuid

2009-03-18 Thread Bill Hart
> By the time we are in config.guess , we allready know that we are either 32 or > 64 > Pff, gosh I'm dumb sometimes. Of course we do. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to t

[mpir-devel] Re: x86_64 cpuid

2009-03-18 Thread Jason Moxham
On Thursday 19 March 2009 01:44:19 Bill Hart wrote: > 2009/3/19 Jason Moxham : > > On Tuesday 17 March 2009 18:40:30 Bill Hart wrote: > >> Jason, > >> > >> I had a look over this and it looks brilliant. This really deals with > >> a number of tickets, which is great! > >> > >> Some comments: > >>

[mpir-devel] Re: x86_64 cpuid

2009-03-18 Thread Bill Hart
2009/3/19 Jason Moxham : > > On Tuesday 17 March 2009 18:40:30 Bill Hart wrote: >> Jason, >> >> I had a look over this and it looks brilliant. This really deals with >> a number of tickets, which is great! >> >> Some comments: >> >> The name athlon seems inconsistent with k5, k6, k62, k63, k8, k10

[mpir-devel] Re: x86_64 cpuid

2009-03-18 Thread Jason Moxham
On Tuesday 17 March 2009 18:40:30 Bill Hart wrote: > Jason, > > I had a look over this and it looks brilliant. This really deals with > a number of tickets, which is great! > > Some comments: > > The name athlon seems inconsistent with k5, k6, k62, k63, k8, k10. It > seems to me that Athlon and k7

[mpir-devel] Re: x86_64 cpuid

2009-03-17 Thread Gonzalo Tornaria
On Tue, Mar 17, 2009 at 3:40 PM, Bill Hart wrote: > I also wonder if there is a way to distinguish intel family 15 and 22? family=6 for core2 always (family=15 is p4) model=15 for "normal" core2 and xeon model=22 (=16h), for celeron (I assume core2-celeron) model=23 (=17h), for "extreme" core2,

[mpir-devel] Re: x86_64 cpuid

2009-03-17 Thread Bill Hart
One of the issues which will confront us soon is the fact that Intel have stopped upping clock rates and have started introducing more cores, and AMD have followed suit. I predict that eventually we are going to want to start distinguishing these. Perhaps we need: k8, k8x2, , core, corex2, core2

[mpir-devel] Re: x86_64 cpuid

2009-03-17 Thread Bill Hart
For amd we'd have to have: K5, K6 (mmx), k62 (k6-2, mmx, 3dnow), k63 (k6-III, mmx, 3dnow), k7 (mmx, 3dnow), k7sse, k8 (all sse2), k8sse3, k10, geode? It looks to me like k9 never materialised, and if it did, it represents dual core AMD k8's. k11 is supposedly Turion Ultra. Bill. 2009/3/17 Bill

[mpir-devel] Re: x86_64 cpuid

2009-03-17 Thread Bill Hart
Jason, I had a look over this and it looks brilliant. This really deals with a number of tickets, which is great! Some comments: The name athlon seems inconsistent with k5, k6, k62, k63, k8, k10. It seems to me that Athlon and k7 are synonymous, so shouldn't we use the latter? I also wonder if