On Thursday 19 March 2009 01:44:19 Bill Hart wrote: > 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. >
By the time we are in config.guess , we allready know that we are either 32 or 64 > >> 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 -~----------~----~----~----~------~----~------~--~---
