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 there is a way to distinguish intel family 15 and 22? Is one lot high end Xeon as opposed to low end core2? If we can figure out what the reason intel had for splitting this lot into two families, we can probably be more precise about something. Also, I'm not seeing nocona any more? We originally distinguished p4, prescott and the 64 bit versions which we called nocona. I now see prescott, netburst and pentium4. Admittedly nocona is a codename for a certain Xeon revision (basically the Xeon for which intel introduced Intel64), and it is also used by gcc to identify 64 bit p4's, so it seemed convenient to Gonzalo Tornaria and I to use it to distinguish 64 bit p4's. Now I think it wasn't such a good idea as some prescotts are actually 64 bit. But what is the difference between pentium4 and netburst? I suppose the other thing that worries me slightly is that we now have AMD's named by core revision and Intel's named by a mixture of marketing names and technologies. I'm actually not worried about that as such, as it might be the best way to do it for now until the whole mess clicks into place for us. But the intel chips do seem to have had internal core names as well. Roughly speaking, here is a list: 386 -> i386 486 -> i486 pentium ->p5 pentiumpro ->p6 pentium2 ->p6 pentium3 ->p6 pentiumM ->p6 yonah -> p6 core duo ->p6 pentium4->p68 netburst -> p68 "nocona"->p68 prescott->p68 core2 -> p6 itanium -> p7 (not x86) nehalem -> i7 atom It's not clear to me why we are distinguishing core2/penryn and not core2 family 15 and core2 family 22. If we distinguish penryn, why not conroe, allendale, wolfdale, kentsfield, yorkfield, penryn and merom? I'm not suggesting we distinguish all these, as they are all core2. I'm just wondering, why distinguish penryn. One other confusion of course is that prescott was a major reworking of the previous netburst cores, which according to wikipedia made people wonder why Intel didn't call it pentium5. Intel apparently tried numerous core redesigns as they had initially thought clock speeds of the p4 (netburst) architecture would scale to 10GHz. That's one of the reasons we had distinguished pentium4 and prescott in the old naming system (that and the SSE3 revision of prescott). Another confusion is that intel called netbust p68 whereas everyone else called it p7. They called itanium p7, which is not an x86 processor. Another confusion is that pentiumM's revived the p6 architecture, being a reworking of prior pentium III's. But they were perhaps sufficiently different to be considered a separate thing. It makes me wonder if we shouldn't use a naming system like: k5, k6, k7, k8, k9, k10, etc p5, p6, p7, i7, atom Of course we should distinguish prescott and core2: p7pres, p6core2 For systems where there can be confusion over non mmx and mmx, and sse revisions, we could append that: p5, p5mmx, p6, p6sse2, p6sse3, etc That only leaves the lahf issue. We'd have to have p7, p7lahf, p7pres I suppose. Of course we'd not be distinguishing pentiumpro, pentium2, pentium3, etc. with this naming system, but if you think about it, we don't have separate code for these anyhow, and there probably wouldn't be any difference, even if someone could be bothered writing it (hardly likely). They all currently get assigned to the p6 directory (I think). I don't know if there is any ideal solution here. The one critical piece of missing info now is whether it is a 32 or 64 bit chip. For AMD it is trivial I think. But we'd have to have p7 and p7_64, p7pres and p7pres_64 I suppose. It's not clear if there are any other possible confusions. Also p7pres may be unnecessary, as they are distinguished by their SSE3 revision. Could we/should we have: p5 (pentium), p5mmx (pentium mmx), p6 (pentium II, Celeron, Pentium pro, Xeon), p6sse (pentium III, Xeon), p7 (pentium4, Xeon), p7lahf, p7sse3 (prescott), p7sse3_64 (nocona), p6sse2 (pentium M, celeronM), p6sse3 (yonah/core), p6core2 (core2), i7 (nehalem), atom? sse2 was introduced from the very first pentium4 (p7), so no need for p7sse2 sse3 and intel64 seem to come together in Xeons, intel64 only comes with chips since prescott in Celeron D and Pentium 4 chips, all pentiumD's are 4 bit and have SSE3 and similarly for pentium extreme, so there is no need for p7sse2_64 as it doesn't exist. Eventually with some work, we may be able to get rid of p7lahf. Apparently the cmov instruction available on some chips but not others is also used a lot in optimisation, making many things faster. I don't know that we use it at all though, yet. (The brackets indicate what processors start with this core and are not part of the proposed names.) Technically p6core2 is inconsistent naming. It should be p6_64. A final note: there may be some confusion with SSE revisions of AMD chips, so we might need k8, k8sse3, etc. 2009/3/17 Jason Moxham <[email protected]>: > > > In the svn branch x86_64-cpuid is my attempt at re-organizing the x86_64 > processors. > > The file cpuid.c is now the only place where detection takes place , before we > had config.guess and the two fat.c , they now just #inlcude "cpuid.c" > > cpuid.c returns the microarchitecture of the processor only , no consideration > of what code will be run. > > in 64bit mode we have > x86_64(default) core2 penryn nehalem atom netburst netburstlahf k8 k10 > > in 32bit mode we have > i486(default) pentium pentiummmx pentiumpro pentium2 pentium3 core pentium4 > prescott k5 k6 k62 k63 athlon viac3 viac32 core2 penryn nehalem atom k8 k10 > > I've not changed the x86 CFLAGS or asm path order for static/fat ( I hope) > > for non-fat builds this is the asm path search order > > x86_64-*-*) > path_64="x86_64" ;; > netburst-*-*) > path_64="x86_64/netburst x86_64" ;; > netburstlahf-*-*) > path_64="x86_64/netburst/netburstlahf x86_64/netburst x86_64" ;; > k8-*-*) > path_64="x86_64/k8 x86_64" ;; > k10-*-*) > path_64="x86_64/k8/k10 x86_64/k8 x86_64" ;; > core2-*-*) > path_64="x86_64/core2 x86_64" ;; > penryn-*-*) > path_64="x86_64/core2/penryn x86_64/core2 x86_64" ;; > nehalem-*-*) > path_64="x86_64/nehalem x86_64" ;; > atom-*-*) > path_64="x86_64/atom x86_64" ;; > > there is a similar one in configure.in for 64bit cpu in 32bit OS > and a similar fat path search order in fat.c > > I've tested on a few machines , and it all appears to work. What I will do is > fake each cpu and test the paths that it uses. > > Jason > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
