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, core2x4 or something like that. I suppose we can cross this bridge when we come to it. Bill. 2009/3/17 Bill Hart <goodwillh...@googlemail.com>: > 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 <goodwillh...@googlemail.com>: >> 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 <ja...@njkfrudils.plus.com>: >>> >>> >>> 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 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 -~----------~----~----~----~------~----~------~--~---
