Timeline for Was there a different 64-bit design for x86 from Intel?
Current License: CC BY-SA 4.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 22 at 13:45 | comment | added | Peter Cordes | @PowerLuser: chipsandcheese.com/p/… is a modern write-up on Netburst (focusing on 90 nm Prescott and later), with a block-diagram comparison to PIII. realworldtech.com/merom/3 also compares P-M and Core 2 with P4. realworldtech.com/willamette-basics/4 / realworldtech.com/willamette-architecture from Paul DeMone (who wrote the RWT deep dives before David Kanter) compares P4 to PIII. The trace cache makes its front-end a completely different beast, different from the ground up. | |
| Oct 22 at 13:41 | comment | added | Peter Cordes | @PowerLuser: It wasn't until Sandybridge (realworldtech.com/sandy-bridge) that Intel made a big enough change to call it the start of a new family of microarchitectures. SnB-family is a blend of P6 with some Netburst ideas, like the PRF, simplified uop format to allow larger ROB / scheduler, and a uop cache that isn't a trace cache (so avoids duplication), while still having strong legacy-decode throughput since transistor budgets are bigger 10 years later. More execution ports / wider pipeline aren't fundamental changes; e.g. Alder Lake isn't a huge change from Ice Lake. | |
| Oct 22 at 13:35 | comment | added | Peter Cordes |
@PowerLuser: That's correct. Netburst (P4) is a very different uarch than P6-family (PPro/PIII / Pentium-M / Core 2 / Nehalem). Netburst has trace cache (with weak decoders to refill it), a physical register file (vs. P6 keeping speculative outputs directly in the ROB (ReOrder Buffer)), and double-pumped ALUs (0.5 latency for add eax, ecx on Williamette / Northwood). Also extra uops for more instructions than P6. P-M / Core 2 are very clearly built on PIII ancestry, still having many of the same performance quirks like register-read stalls (agner.org/optimize/microarchitecture.pdf).
|
|
| Oct 22 at 11:56 | comment | added | Raffzahn | @PowerLuser Well, I guess it's debatable. IMHO Netburst is just a finer, more stretched implementation of the P6. Less execution ports but more buffers and intermediate steps in preparation/handling. Not really a new architecture. Core (without 2) in turn completely redesigned the most important part of a CPU, the execution unit by increasing the ports and sharing them between Integer and FP. But yeah, classification may come down to how one locks at it as both are based on P6 but develop that base in different ways. To me Core features way more basic changes than Netburst. | |
| Oct 22 at 11:35 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 924 characters in body
|
| Oct 22 at 10:56 | comment | added | Raffzahn | @SebastianKoppehel Viewing the full interview I get a feeling that it may be misleading about the timeline of the Pentium 4's 64 bit capabilities, as the Prescott was designed with AMD64, but disabled at first as there was no intention to support it outside the Netburst based Xenon series (Nocona). ... let me incorporate that. | |
| Oct 22 at 10:02 | comment | added | PowerLuser | Perhaps I'm misinterpreting the paragraph glossing over "The Early Naughties", but I am quite confident that the Pentium4 Willamette was in fact the new x86 microarchitecture while Core/Core2 took a walk back to the P6 roots of the Pentium-PentiumIII, contrary to what the phrasing of this paragraph would seem to imply. It is in fact a point of note here that Intel tacked on 64-bit processing to the later generation P4 family while we didn't see 64-bit processing for 'upgraded' P6 Core until the Core2 family came out - Core was still 32-bit having riffed off of the PIII designs. | |
| Oct 22 at 7:04 | vote | accept | DarkDust | ||
| Oct 21 at 23:45 | comment | added | Raffzahn | @marcelm Not sure where you see any 'ad-hominem' part, as I'm purely asking how come. I'm genuinely puzzled how you come up with a connection that is neither explicit written, nor obviously implied or can IMHO derivative from the context. | |
| Oct 21 at 23:43 | comment | added | Raffzahn | @SebastianKoppehel Great find. Thank you. It might be useful to note that what he describes covers a good 6 years. between AMD's initial x64 offering and Vista (Longhorn) lies the delivery of Server 2003 and XP, both with 64 bit support. (Also, seems to be a section of a way longer interview ... I'm of viewing more of it :)) | |
| Oct 21 at 20:20 | comment | added | Sebastian Koppehel | Here is Dave Cutler telling Microsoft's side of the story (or his part of it). If you watch the whole video, you'll note that this also happened at a time when there was considerable internal division and quality (security) problems at Microsoft. | |
| Oct 21 at 12:51 | comment | added | John Dallman | @TooTea: "MS could well have expected all existing 32-bit x86 deployments to migrate to whichever of IA-64 or AMD64 wins the battle," MS management might have expected that, but not engineering. The x86-32 hardware in Itanium and Merced was slow by the standards of the time, because it was strictly in-order. Anyone who switched from a Pentium Pro/II/III to the x86-32 on IA-64 would have seen major performance losses. The change in McKinley to transpiling into IA-64 native code improved matters, but it was still slower than any OoO x86 implementation. | |
| Oct 21 at 8:57 | comment | added | marcelm | @Raffzahn There's no need for passive-aggressive ad-hominems. I pointed out something in your answer that I found inconsistent and unclear. Do with my feedback what you will. Getting all defensive about it seems like the least productive option to me. | |
| Oct 21 at 8:52 | comment | added | Raffzahn | @marcelm I would think anyone reading an answer would as well read the question setting the stage, or at least the headline, wouldn't it? | |
| Oct 21 at 8:42 | comment | added | marcelm | @Raffzahn Your answer up to that point makes no mention of Intel64. In fact, the paragraph before it explicitly says "IA-64, Intel's sole 64 bit product in form of the Itanium CPU" excluding the existence of Intel64. The context you're referring to is completely missing. | |
| Oct 21 at 8:39 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 9 characters in body
|
| Oct 21 at 8:38 | comment | added | Raffzahn | @marcelm The topic is kernel level. Windows 2000 already provided an IA64 capable kernel in addition to x86 (IA32). The issue at hand was to add one (AMD64) or two (AMD64+Intel64) x86-64 kernel variants. All described in that section when reading in context. | |
| Oct 21 at 8:33 | comment | added | Raffzahn | @JohnDallman Yeah. Only a good employee is a surviving one, and good employees do tell what their bosses want them to tell. Plus some may even believe it at times of great hype :) | |
| S Oct 21 at 8:28 | history | edited | Raffzahn | CC BY-SA 4.0 |
Minor spelling issues
|
| S Oct 21 at 8:28 | history | suggested | Snostorp | CC BY-SA 4.0 |
Minor spelling issues
|
| Oct 21 at 8:26 | comment | added | Raffzahn | @PeterCordes Ripping 4 words out of its context (paragraph) isn't helpful. There's no doubt that x86-64 was coined by Linux development to have a vendor neutral term and that it happened early on. But Linux-DEV isn't exactly general public. AMD64 / Intel64 and EM64T was what the talk was about. It took many years to outlive that fight and accept x86-64 by most people - and thats what's being said. History as it happened. | |
| Oct 21 at 8:23 | comment | added | John Dallman | When Intel announced EM64T, they claimed that IA-64 was too demanding of current technology, and would be back in a few years. Of course it never was. About 2009, I mentioned this to an Intel person, who was a bit surprised that nobody was asking about it yet. "Nobody outside ever thought it would come back. It was clearly a turkey." "But why didn't anyone say so?" The industry was just humouring you. You had to say those things, even though they weren't plausible. Why waste time?" | |
| Oct 21 at 8:23 | review | Suggested edits | |||
| S Oct 21 at 8:28 | |||||
| Oct 21 at 8:05 | comment | added | TooTea | @marcelm It's not an extension on the HW/ISA level, but it can be seen as an "extension" on the product/marketing level in the sense that it would be sold as an upgrade path for customers currently running on 32-bit x86. Although it's not nearly as directly compatible as AMD64, IA-64 still promised a degree of x86 compatibility, so MS could well have expected all existing 32-bit x86 deployments to migrate to whichever of IA-64 or AMD64 wins the battle, instead of a completely independent 64-bit arch like the Alpha (for which there was a Windows port at some point). | |
| Oct 21 at 7:37 | comment | added | marcelm | "But MS did neither have capacity nor any intention to support two different 64 bit extensions for x86 at kernel level" - This implies IA-64 is a "64 bit extensions for x86", which it definitely is not. | |
| Oct 21 at 4:23 | comment | added | Peter Cordes |
today morphed into x86-64. - The term "x86-64" dates back to at least 2000, with discussion between AMD CPU architects and GCC / Linux kernel developers taking place on x86-64.org mailing lists (e.g. feedback from kernel devs led to syscall masking RFLAGS so interrupts could be disabled on kernel entry before swapgs). The wayback machine shows it existing as early as Aug 2000 under that name. So [citation needed] for MS's shortened x64 predating x86-64. Also the fact that the "public" chose to call it x64; that was AFAIK MS's doing.
|
|
| Oct 21 at 2:44 | comment | added | Miss Understands | Damn, it's rare that an answer at stock exchange is that extensive and interesting. You deserve 100 points for it. | |
| Oct 20 at 23:24 | comment | added | Raffzahn | @JohnDallman Yes, that's part of the story, except as I was told, their 'we do different' started way before accepting they had to. It was more an 'alternative offer' yeah, if you want it, we do it, but it'll be different. And all of that was mostly hot air, hoping to slow development down and make MS miss the deadline. But AMD delivered on their promises during that time to MS. It changed when they realized that Server 2003 will be delivered with AMD64 support and none of their non-finished proposals (Might also have helped that there were similarities with DEC Alpha (Thanks to Mr. Meyer :)) | |
| Oct 20 at 22:30 | comment | added | John Dallman | I had a slightly different story from a senior AMD person in 2005 or 2006. Once Intel accepted they had to do a 64-bit x86 they wanted to make it thoroughly incompatible with AMD64, with differently encoded instructions. The idea was to force software producers to produce separate Intel and AMD builds, in the hope that they would not bother with AMD versions and AMD would be forced out of the market. Microsoft said they couldn't prevent Intel doing that, but they would not produce Windows for it. Intel had to climb down. | |
| Oct 20 at 17:07 | history | answered | Raffzahn | CC BY-SA 4.0 |