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 are synonymous, so shouldn't we use the > latter?
I'll change athlon to K7 > > 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. > As far as I can tell we have for "core2" branded processors F=6 M=15 core2 65nm F=6 M=22 core2 65nm lowend cpu? F=6 M=23 Penryn 45nm F=6 M=29 Penryn 45nm dunnington Penryn have a faster div instruction and a faster sse shuffle (you can allready see it effect on the current shifting code) As far as I know there are no architectural differences for 15/22 or 23/29. There are differences in number cores and cache sizes , but we dont yet care about that. The existing mpn/generic/sumdiff_n.c code does depend on L1-cache size (a little bit). > 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? > none > 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. > It wasn't always clear what names were used for what purposes , my intention was that the names should correspond to the microarchitecture , and I only did the 64bit side , I have left the 32bit alone. Lets get the 64bit side sorted first. > 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. > Don't see why we want to know this? > 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 -~----------~----~----~----~------~----~------~--~---
