Merced Architecture Specs

Hasdi R Hashim wrote in to tell us that Intel has released theInstruction Set for the merced. You'll enjoy it if you're the sort that gets off on this stuff anyway.. "

Comments

Where is the rest?

[Anonymous Coward]

This "documentation" is coming with a company that leaves their products only half documented and little white lies. Where is the "Appendex H." on IA-64? And how much undocumented information won't even make it into the NDA Appendex H? And for the documentation they have released, how much will the actual product operate to spec? Was this documentation also thrown together by college interns and never proof-read like Intel has done in the past.

Personally, I don't see how IA-64 has any market. For several years it will remain over-priced for the workstation market. So, that leaves it "targetting" a server market. But given Intel history, can we truely trust them with our terra-byte databases and other critical *server* operations. Well... lets see the history and then decide:

Intel reliablity example 1) Pentium 60-90 is released:

Intel Marketing: The Pentium has a FPU that is up to 10 times faster than the i486 (notice, FPU is a key feature at this point!)

Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU

Intel Responce: Error only occurs in 12th decimal place and hence is not important. No CPU is 100% error free and this error would only occur once in a million years by the average computer user. For those that it is important to, a software fix is possible, the speed difference caused by the software fix should not be a problem for the user (Pentium FPU importance and speed is downplayed by Intel)

Internet FAQ responce: A simple division problem can reproduce the bug with errors occuring in the *9th* decimal place

IBM responce: FPU's handling of subtraction/addition can create the situation where the bug is reproduced in the next division step. A speadsheet user will run into the bug on average of once a *day*. IBM will discontinue it's pentium lines until Intel fixes the problem.

Intel reliabilty example 2) EIDE pre-fetch and Intel's motherboards with PC-Tech EIDE chipset and "Intel Inside" quality assurance

Intel Marketing: computers performance should become much faster because of Intel's push to support pre-fetch capablity in EIDE controllers and OS developers should take advantage of this feature whenever possible with no exception (pre-fetch is a key feature!)

Intel to MicroSoft: the PC-Tech EIDE chipset has a known bug which will corrupt the data with pre-fetch is enabled. When Windows '95 detects this chipset it should disable pre-fetch

Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives. The problem is impossible to diagnose until PowerQuest discovers the bug Intel was already aware of and releases information on it. OS/2 and Linux patches appear shortly after the PQ announcement. These patches increase reliablity and hurt performance by disabling the buggy pre-fetch implimented on the PC-Tech EIDE chipset

Intel's responce: pre-fetch does not have that much of a performance gain (complette contradiction to previous Intel documentation) and disabling the pre-fetch should have no noticable impact. Since the offical (non-beta) version of Windows '95 does this fix for the PC-Tech chipset since the beginning, this bug is a non-issue

Moral of story: "Intel inside" quality assurence on their motherboards only assures reliabilty of drivers for MicroSoft Operating Systems. It provides no quality assurence of the system performance or reliablity following Intel's "documentation"

Intel reliablity example 3) F00F bug

Intel marketing: the Pentium architechure is a huge improvement over i486 and is Intel's workstation and *server* quality CPU (server capablity is a key feature)

Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu

Intel responce: the problem should never occur in actual code and should it occur then it only requires the user to turn off and back on the machine hence this is not really a problem (The key feature of server quality is clearly downplayed here. How often do the users even have direct access to a server to restart it?)

So, is IA-64 another Intel reliablity example? According to Intel (no CPU is 100% error free), yes, it is another example that "Intel Inside" is a *warning label* that Intel "quality" assurance has been provided. History has shown that the only quality that Intel assures is that what Intel marketting considers key features WILL NOT operate as documented and Intel is prepaired to downplay the importance of the key feature.

So, IA-64 will be priced to target the "server" market. But in it's first three years of production will it be as *documented* and provide the same *quality*, reliablity, and *work-around free* performance that proven 64 bits systems do (such as IBM RS/6000, UltraSparc CPU and clones, Compaq/DEC Alpha)? History has spoken, has it not?

Oh. And I think my question still stands. Where is the REST of the IA-64 documentation (that IA-64 will fail to follow)? :-)

Re:Where is the rest?

[Anonymous Coward]

Personally, I don't see how IA-64 has any market. For several years it will remain over-priced for the workstation market. So, that leaves it "targetting" a server market. But given Intel history, can we truely trust them with our terra-byte databases and other critical *server* operations. Well... lets see the history and then decide:

There is only one problem that can kill an CPU architecture: lack of address space. Nowadays we already have Freebsd.org that uses 4 GB, some people whinning because Linux only gives 2 GB (or 3 GB) to user programs, and many people complaining because Linux as a 2 GB limit on files. I personnaly was lucky enough today that Microsoft couldn't design an extensible filesystem, so that I was able to copy the default installed 2GB FAT partition to a Linux partition. It is clear that the x86 (IA-32) architecture is dying ; IA-64 is a necessary evolution. Would you use a 8 bit processor with 256 bytes or 64Kbytes addressable memory today ? No. Or do you think that 4 GB should be enough to anyone ? Hennessy&Patterson give a list of some machines that died because of lack of address space: PDP-8, PDP-10, PDP-11, i8080, Intel 8086, AMI 6502, Zilog Z80, Cray-1, Cray X-MP. They also say something like "in the 90ies, when the 32 bits will come to their limits, it would be interesting to see is the same choices about addressing and segmentation will be done again". If you are saying that IA-64 has no market right now, then it would means that Intel has brought to us innovation faster than necessary. This isn't necessary evil.

You then complain about Pentium bugs: Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU
Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives.
Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu

So ok the first one was a serious CPU bug that could have been avoided by tests. But you fail to give an exact account of all the bugs of others CPU, so you can't tell whether Intel is bad or not.

Also, since Intel is mainly in the consummer market, I don't expect it to send instantly an Intel Bunny People to change my CPU at once, when they discover a bug. This is bad and wrong, true, but this is expected ; most companies would operate that way ; they try to minimize, and lie, etc... because it would be a net loss of revenue. It's up to the consumer to defend himself (up to the law to provide the ways to defend himself, and up to the magazines to have competent enough journalists to report hidden problems, up to the user to buy these magazines, etc...). Look, my CD burner is a Philips CD-2600. I bought it, then I discovered people were saying lots of bad things about its reliability ; and then latter, mine died (now replaced by my vendor by one which happens to work "most of the time"). Did Philips come to change my CD ? No. When you go to www.philips.com, CD-R section, do you find information about possible problems on CD-2600 ? No. Is Intel worse than others companies ? I don't know ; I do know that many chipsets for miscellaneous cards have also their share of bugs.
Your point is valid for the server market ; but maybe Intel managers aren't too stupid to release completly untested insufficiently tested IA-64 chips, when they are targeting the server market. What do you think ? The quality manager comes and says to the boss, Andy Grove: "I need 1 month and $100000 to release a broken IA-64 (broken with a probability of 99.99% on simple applications), 12 months and $1 million for a probability of grave bugs of 1%, or $100 millions for a probability of 0.0001%". Andy Grooves asks "how does the 0.0001% compares to Alpha?". The manager answers "it is a bit higher, maybe 3 times, but same order of magnitude". So now what do you think Grove says ? "Go for the $100000, I had always dreamed to screw the entire planet! Our reputation will be ruined, and Intel will go bankrupt! Hooray!!!" ?????? I know this is slashdot.org, but try to be a little rational.

Maybe you are complaining that Intel can't design chips ? But at equal frequency brand new design such as PowerPC are only 10% faster than the PII crippled with all its compatibility stuff. Frankly I've seen major design blunders much more frequently in software (Redmundian, or in Unix, thus inherited by *BSD/Linux). When I was using a 286, I sure was pissed to have a processor with such a poor/baroque design ; but now I have a PII, and it is pretty respectable.

For undocumented features, some of them are not disclosed to keep the competition to make a 100% compatible clone, and some because they don't want people to use minor features that will cripple the future evolution of the processor.
Keeping the competition from doing a clone is not cool, but again is to be expected (but then, people aren't obligated to make clones, right ? Look at the miscellaneous RISC. Nobody does a Windows 2000 clone nowadays). We have to make pressure on Intel for it to avoid lame techniques that would be the consequence of its monopoly, though.
Keeping some non-vital information secret, is a defensive technique, in order to keep the users from doing something stupid, such as gaining 1% speed but at the expense of crippling to future processors with backward compatibility for their hacks, and maybe forbidding a 2x speedup. An example would be downloading microcode ; if users knew how to, and did that, then Intel would be forced to keep all the next CPUs compatible with this user-defined microcode ; maybe they would have to add a layer of indirection on next generation processor: microcode for microcode (much like nowadays x86 are translated in RISC86 instructions. If you could wrote directly RISC86 instructions, then Merced would have to translate also your RISC86 instructions to IA-64, at a performance cost). Well, maybe only if some clown at Redmond had done that, trying to optimize the in-kernel IIS server in order to improve on some benchmark, but you get the idea.

I'm tired of people critizing Intel on shaky grounds ; it is true that there are more cleaner designs than the IA-32 architecture, and maybe better than the IA-64, but what we have is somewhat decent. If you want to criticize, please do compare to other companies.

Re:I laughed, I cried...

[jpick]

A Linux port has underway for quite awhile already. Intel and Cygnus have press releases saying who's working on it. VA, HP, SGI, Cygnus are all working on it under NDA.

Cheers,

- Jim

Re:I laughed, I cried...

[Anonymous Coward]

"Not that I am vary worried about Merced being late, I'm probably buying a dual processor alpha anyway."

Glad to hear it.. always nice to see more users added to the Alpha Linux community. You also may want to wait a while until the AMD K7 hits the market. As you probably know, the K7 and 21264 (EV6) processors use the same bus protocol. It is widely rumoured that mainboards which accept either the K7 or an Alpha processor are in development.
That will be a very powerful option, especially for Compaq - using the same components, sell K7 systems to the usual userbase and Alpha system to the power user/server market.
Very sneaky indeed.