2009/3/19 Jason Moxham <ja...@njkfrudils.plus.com>: > > 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)
Interesting. Didn't know that. > > 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. OK. Fair enough. > >> 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? Doesn't it limit the different ABI choices that are possible? Wait, how does it currently decide which ABI to use? Does configure decide that aside from what config.guess says. I thought I recalled that this is why Gonzalo and I had nocona. Gonzalo, do you have an opinion of this, or have a better recollection of what we had figured out? Bill. > >> 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 -~----------~----~----~----~------~----~------~--~---
