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 Hart <[email protected]>: > 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 -~----------~----~----~----~------~----~------~--~---
