Slashdot Mirror
Merced vs McKinley
Single GNU Theory writes "HP suggests that people skip Merced in favor of McKinley. I think the reason is that HP has a bigger influence on McKinley's design than Merced's, not because the release date for Merced has been delayed past the expected release of McKinley... "
NT is a better design than 95/98 - that doesn't make it "good". Too much stuff running in ring-0. Bears a bit too much similarity to DOS and VMS (and win95/98) for my taste. Still tends to crash and bluescreen more than a "high-end" OS should. Win2k doesn't seem to be doing much better, and with all the extra bloat... well, you know how that goes.
Also, Windows 95/98 and NT are still very tied to 32-bit systems, esp. the ix86. Yes, NT got ported to PPC and MIPS (both of which are dead projects) and AXP (which apparently is now being abandoned as well). It ran in 32-bit mode on all the processors it ran on (fine for PPC, but AXP and recent MIPS designs are 64-bit, and that wastes a lot of potential).
To go 64-bit, Microsoft will probably end up redoing the whole API all over again, and all the apps will have to be rewritten to use the new APIs. It won't be pretty. (Think Win16->Win32, but probably an order of magnitude more painful.)
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
In the late 80s Intel released two RISC designs. Neither of them gained significant traction in their intended market segments. They failed for a variety of reasons, only some of which were technological. The biggest reason was that no body wanted to buy a faster cheaper chip from Intel unless it could run x86 code.
This was good and bad for Intel. It was bad because Intel was stuck selling a chip which, for a given production volume, would never offer the same price performance as a RISC chip at the same production volume.
It was good for Intel because they had something that everyone wanted and they could churn out so many of them, and sell them at such fat margins that the bad part didn't look quite so bad.
Of course, ultimately, Intel was going to have to lay the x86 design to rest, but, as time went on, and competitors in the x86 market got better, it became even more difficult to make an abrupt transition.
They needed a guaranteed customer base, and they found that in HP. HP had been producing their own RISC chips, and had begun design work on a radically new chip architecture, but they had pretty small sales volumes and bringing out a new chip family is really, really expensive.
So, Intel and HP struck a bargain. Intel would make use of HPs design resources, but they would shoulder the multibillion dollar costs of actually putting a finished design into production. HP would buy the chips (at a discount, I imagine) and sell systems using them, guaranteeing Intel a substantial customer and they would avoid a lot of outlays to bring their own chip to market.
Rather, merced never will. However, Intel is planning a line of IA-64 chips for desktops, to be available in 2002 or something. Apply the standard rate of deadline slip, and get 2005...
Also, from rumors I heard, the HP engineers who were working with Intel on the design of the Merced got fed up with how things were going there. That might have something to do with why they kinda wandered off on their own and did the McKinley design. (Note: this is rumor mixed with my personal speculation - don't take this as the official story.)
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
The "Willamette" chip is due out next year, I believe. I'm curious whether they ever intend to dump IA-32 entirely or continue the IA32/IA64 split indefinately.
To answer your first question, it's very simple. HP makes better chips than Intel, but designing and bringing a new chip architecture to market was getting prohibitively expensive for HP. The partnership was a natural one for both companies.
McKinley is an HP designed rework of the original Merced chip. Intel liked it so much they exercised their rights to it.
Saying that HP "had more influence" on McKinley is an understatement. McKinley IS an HP chip, not an HP/Intel chip.
- Necron69
The last RISC arch worth noticing was the PPC, and RISC was already looking pretty obsolete then. My guess is there won't be another significant one, any more than there's likely to be another signficant CISC arch.
Remember, NT did portability long before Linux did, though not before UNIX. There won't be any problem getting NT up and running on IA64. However, when you're upgrading to native versions of your OS and apps anyway, that's a good time to consider a switch to a new OS--which gives Linux a pretty good chance to gain ground.
A lot of shaves and haircuts.
----
----
Open mind, insert foot.
You are so far off it's funnt :P
just = (My)Opinion.toCents();
t=y ;)
just = (My)Opinion.toCents();
HP had implemented the concept of object code translation (OCT) and MILLICODE long before DEC had FX!32. HP used it in the first transition from HP3000 "classic" stack architecture (16-bit) to PA-RISC (called HPPA back then). The PA-RISC hardware supported trapping on the old achitecture's instructions and vectoring into a table of PA-RISC instructions which performed the equivalent operation. This table of instrucitons was like microcode, but not housed in a control store - rather kept in memory. HP called it MILLICODE and performace was 70-90% of native PA-RISC code. The first versions of the HP3000 PA-RISC machines actually ran large portions of the operating system (MPE-XL) in this "compatibility mode" using the millicode; this included the file system. This was all back in circa 1984. And when did DEC come up with FX!32? The OCT was a compliler from HP3000 "classic" into a PA-RISC executable. Once the OCT was performed on a "classic" program, the resulting executable ballooned up in size as the PA-RISC code was appended to the file. When run on a PA-RISC machine, the PA-RISC code executed. If the binary was executed on a legacy HP3000 "classic" machine, the still imbedded HP3000 code would execute. All in all, it worked pretty well.
>Does anybody really think Intel can get people to jump to a new architecture?
Intel doesn't have to get anybody to jump to a new architecture. People are not going to have much of a choice. The next Windows platform will be designed for Intel's new chips and then all the software companies will have to make their software compatible if they want to stay in business. People will keep running x86 OS's and apps on old Intel's and AMDs, but once application support for the platform dies out and everyone's using the new arch. it won't matter. Intel just has to get through the transitional phase, which is why they're teaming with up with HP to get the help/support.
-Zulu
HP saying that McKinley will do better than Merced might have something to do with INTEL saying that they don't expect Merced to do well at all and that they are counting on McKinley to be their next moneymaker. Got nothing to do with how much say HP has. If the mother thinks her daughter is ugly, watch the hell out.
Is the Merced i386 archetecture? What new chip are the normal, non-server running people supposed to put in thier new hopped up PCs? Does intel have an offering, or is the future looking very AMD?
I keep trying to pick fights, but I can't shake this Excellent karma.
You make some statements that are misleading.
Why are HP push customers toward systems that are both HP-PA and IA-64 capable (recommending HP-PA until McKinley comes out) and being the first out with their Unix on Merced mutually exclusive? I think not. There is no reason that HP can't port HP-UX to Merced and recommend customers purchase their N class systems which reportedly are capable of supporting both HP-PA and IA-64. If their HP-PA CPUs out-perform Merced then it would only make sense to purchase those CPU's and exchange them for McKinley CPU's when they come out.
It's probably BECAUSE of performance concerns that they recommend HP-PA CPU's until McKinley comes out, skipping over Merced CPUs. They would be dis-honest if they did not recommend otherwise and you can be sure that they would get "caught in the act" if they tried to fudge the performance specs.
What other chip did Intel come out with that has a comparable design? Forget the x86 architecture. What about their i960? Was that on the same level as the HP-PA, SPARC, Alpha, or PPC?
Personally, I have typically waited for a major jump before upgrading my primary computer. From my Apple ][, I went to an Amiga 2500/30. From the Amiga, I jumped to a Pentium Pro (the Pentium was cool, but my Amiga was doing things as well if not better than the first generation of P5 chips). I have no desire to get a Pentium II or !!! chip right now, since they don't really prove anything other than higher clock rates. The Merced is a good candidate, but the McKinley makes more sense.
Just my 2...
--
Never hit your grandmother with a shovel, for it leaves a bad impression on her mind...
Actually, I do. Still working as my primary machine, though it's being relegated to server work when I inherit a laptop....
My bet: they didn't want to be a market follower, doing "Yet Another RISC ISA", so they looked for something different - and found HPs EPIC. So now they can claim to be a 'market leader'. As to the idea that intel is full of fools that can't design a decent ISA - the X86 (16bit) is very old and not particularly ugly if you compare it with contemporaries (68K is much nicer yes, but it's a later design too). And the IA32 part of X86 - it's not too bad if you consider that they (the designers) had to keep 16 bit compability...
Erik
Has it ever occurred to you that God might be a committee?
Has it ever occurred to you that God might be a committee?
--- Jubal Harshaw
Well, not if you conider a DELL PIII Workstation Athlon ready. You need to remove the motherboard and cpu's and replace them with merced motherboards and cpu's The chasis is about all that is common between the HP N4000 with a PA8500 and one with (maybe if they ever make it) a merced. Go read the HP technical documents for the N-class and you will see that its all a marketing ploy. - I don't know who wrote this.
Hmmm... I'm not sure where you disagreed with me but your second paragraph is pretty close to the point I was trying to make. Sorry if my post was that unclear. ;)
Geeky modern art T-shirts
It's sitting on the floor, on top of my 486 sx 33, which is sitting on top of my 386 sx 16...
McKinley is being desinged at forth collins in colorado by HP's design team. with some straglers from intel thrown in to delay the project. I wonder why the press and it seems everyone else keeps refering to Mckinley as an intel chip when it was designed and implemented by HP! I wonder how much intel will have to pay HP to sell it? Maybe that is the reason HP wants people to buy Mckinley instead of Merced. Now I wonder how dell will like it selling McKinley chips from HP. DELL will be paying HP for every computer they sell.
I found one in a skip - no joke. 128 Mb of RAM on the motherboard as well...
The first PC 'I' bought, a Packard Smell. Still using it. Just put Linux Mandrake on it. Have had to put in another sound card, ATAPI CD, modem upgraded 4 times, several new HDDs, new power supply and 3 RAM upgrades and the chip is still ticking. And you know, Linux recognizes the screwed up FPU and fixes/compensates for it. I'll use it till the fscking thing burns to a crisp.
Yeah - Microsoft can't pull it off.. You know, what with the superior brains they can hire with their money. You can knock Microsoft's consumer OS's, but NT is a pretty good design. You go ahead and make funny little monikers out of 'Microsoft' and 'Windows' all you want, nerdboy. We'll see who comes out on top.
There asking people to skip something thats not out now so they can wait for something thats not out now. Morons.
Let's see, that's 64 divided by 8 which is equal to $8. Wow, that's a cheap chip! But I wonder what it can do.
"We're sorry, but the website you're trying to reach has been disconnected."
Product X isn't ready/sucks/is faulty...but wait for Y which will shortly follow it and will solve all of your problems!!
Does anyone know why Intel decided to get the IA-64 design from HP in first place? I mean, Intel are the biggest chip company in the world right, so wtf can't they make a 64 bit processor on their own when DEC, SUN, HP and company can?
Same thing with the Pentium/K7 situation, Intel have been adding a little cache here, and a few instructions there, and but it takes smaller AMD to come up with the first really new i386 processor in 5 years. What gives?
Anyone still have one of the original Pentium 60's? Q.E.D.
They invented that whole segmentated memory arbritrary 64K boundry thing that keeps me awake reading Slashdot so I guess they don't really suck because otherwise you wouldn't be reading my awesome post so nevermind and don't bother reading beond the period nor responding.
Is anyone porting Linux to HP 8[56]000?
What will be the cost/benefice relationship in both McKinley and Intel Merced?
-- You are in a twisty maze of passages, all alike.
As for why HP would be saying this so publicly now, I can only present some speculation based on rumors and other bits of information:
--
Does anybody really think Intel can get people to jump to a new architecture? Linux and Windblows run 386 instructions. Although you can probably easily recompile Linux and it's applications under a new compiler to gen Merde-ced code; I doubt Mickeysoft can pull it off. No wonder Intel invested in Red Hat; it's their only chance.
I attended a 'HP and IA64' seminar almost 1.5 years ago when IA64 was 'only a year away' from release to initial developers and whatnot (of course which has all slipped horribly). They made a point at the time of their support for IA64 but were still following their own chip development path (the PA8x00) in the event 'something happened.' At the time the 8500 was not released (it was pending in the C360), and the charts used in their little presentation showed a few chips beyond the 8500, 'should they need to be sent to fab if IA64 slips or tanks.' Doing goofy things like adding 2nd FPUs in the chip, restructuring pipelines for better execution, etc... now they have things like the C3000 out, with a 400Mhz 8500, 2Gb/sec bus, etc etc...
It also was a point these steps would narrow the performance gap between the PA8x00 chips & Merced. It makes sense to me (as an HP customer) they make this claim. As to the design infulence issue, I do know Merced was under way when HP joined the fray. It would not suprise me. But I also remember with HP's influence Merced is (was?) supposed to be binary-compatible with PA and they planned major performance boosts with its successor.
Their (stated) primary reason for joining IA64 was because design & fab costs to do all this in-house was just killing them. The 8500 was fabbed by Intel for HP, though HP still did the design. This, of course, is no suprise to anyone.. but it did suprise me how candid the HP rep was about all this. It just screamed 'DOJ probe' all over.
(shit, I wish I still had all the info from that meeting... I think I just tossed it all last week in a fit of weakness and office cleaning. filed under the 'meet what time schedule?' section..)
-fester
-'fester
Months ago, when Intel announced a big slip in the Merced, one of the Microprocessor report dudes predicted that it would continue slipping to the point where it was irrelevant. It would be irrelevant because its release would be too close to McKinley's, whose release date would not slip as fast as Merceds. McKinley's ship date would not slip as fast as Merced's because McKinley had a largely HP design team and the HP design methodology, using a small design team was much better suited for developing an all new processor than intel's approach of throwing 1 jillion engineers at it.
f-cpu.tux.org.
Nuff said.
Join the crew.
The ship sank. Get over it. (This sig was cut out from another's shirt and painstakingly hand-posted)
As far as I know, Merced is Intel's version of IA-64, while McKinley is HP's version. Intel has taken so long on Merced that, HP gave Intel the design for McKinley for some sort of incentive. Otherwise, McKinley may have already been released. Intel certainly didn't want that.
HP's desire to put McKinley on the burner stems from the fact that, for their customers, it is better to wait for better performance. McKinley is expected to arrive not long after Merced. Since HP doesn't want to make twice the number of chipsets (slightly different buses), they would rather design for the faster processor.
The current x86 ISA is an extension of a 25 year old design. PA-RISC is what, 10 years or less.
Compairing the two to reach the conclusion you want us to reach is like showing us a 3 month old baby and a 75 year old man and expecting us to conclude that the parents of the baby are somehow superior to the parents of the 75 year old because the baby has nicer skin!
In addition, Wilamette/Foster, the chip after Coppermine, is a completely new design.
Creating a new design vs. incremental (though not always small) changes is extremely difficult, and it takes a long time to develop. Intel just had a case of bad timing, scheduling their new design to appear close to a year after AMD's.
Actually, the interesting thing about this is that Intel will end up competing with it's own product line, IA-64 vs. Wilamette. If Wilamette is all it's cracked up to be, there may be little reason at all to migrate to IA-64, whether Merced or McKinely.
The enemies of Democracy are
Indeed, Intel has ridden the dead horse that is the x86 to far more victories than anyone could have imagined in the late 80's. This, I think, deserves some respect.
I think it is precisely this ability that has caused them to fail in their attempts to replace it. Nobody wanted a RISC chip from Intel, they wanted a faster x86 that was compatible with their old code and Intel gave it to them.
If they didn't, and tried to force the issue by stopping x86 development, they would have suffered badly because AMD would have eventually filled the void.
They face a similar problem with the transition to Merced or McKinley. It is very likely that in the next few years Intel will permenantly resign from the race for the fastest x86 chip. They are a bit better off now than they have been though, to make this transition. If their x86 business dries up, they could loose some serious revenue, but the P7s should be able to emulate the x86 fast enough, so, if they price them agressively enough, they can still continue to milk a significant portion of the x86 market until the p7 picks up.
Ahh, I remember the day in early '96 when I bought that first Pentium system. Of course the 3V 90s were out, but the performance? Ahh, no difference they said. These days that box is still one of two primary systems (along with a newer K6-2/300) I use at home. It used to run Linux and WFW 3.11, but these days it runs NT4 on 48MB of RAM (Linux on the other machine now, of course). I'll spare you a loving description of my 486SX 25 . . .
Maharet
It's not even intended for the desktop market. It's intended for high end serving. Intel a whole other line of chips that will come after the PIII for the desktop market. Merced won't come anywhere near the desktop until a few years of serving it up.
Who gives a rats ass about Merced or McKinley, the PPC G4's will rip them both a new asshole.
OCT did the translation at "compile" time -- you ran a program called "octcomp" on the HP3000 classic program once. From there on it was running PA-RISC instructions, but limited to 16-bit stack architecture limitations. I.e. it was a PA-RISC program implementing the semantics of a 16-bit program. MILLICODE did the translation on the fly. Each and every program had two stacks, a CM stack and an NM stack. When calling from native mode code, a stack switch would occur to the CM stack. This worked in reverse too. Similar in concept to an Intel "thunk" between 16 and 32 bit, only the 16 bit instructions were executing through PA-RISC architecture assisted millicode translation. Obviously, switching between stacks was just overhead, so if you did something like heavy I/O your performance took a hit (many stack switches). However, if you did some compute bound task and stayed in CM, your performance was pretty good. But then again, how many 16-bit compute engine task were there anyways? BTW millicode was used for extending the PA-RISC instruction set in general, especially for adding complex operations not supported by the minimalist PA-RISC philosophy, e.g. integer multipication. Early versions of PA-RISC didn't have a hardware multiply for integer -- I don't know if that's true anymore. CISC machines at that time would do multiplication through microcode and HP's thinking on this was that implementing a shift-add algorithm in memory would have near identical performance to microcode. Hence, HP thought that there was no need for hardware integer multiply -- just a waste of transistors. Later, when a FPU unit (sold separately as a special function unit) was added to the machine, a hardware integer multiply would be avaiable anyways (or that's how the thinking went). Obviously, PA-RISC hardware has long since added the FPU unit as integral to the chip. Here are some references which mention PA-RISC NM, CM anc OCT. The "Beyond Risc" is an old book that you might find in library. http://www.allegro.com/papers/mpexlperf.html http://www.allegro.com/beyond_risc.html http://www.robelle.com/library/smugbook/cm.html I might have some CM/OCT reference material, but I haven't opened the box it might be in for some 10 years (God I'm getting old).