Become a fan of Slashdot on Facebook


Forgot your password?

Merced Architecture Specs 114

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.. "
This discussion has been archived. No new comments can be posted.

Merced Architecture Specs

Comments Filter:
  • It's a whole book, not just a couple of web pages. All (?almost, anyway) of Intel's online documentation is in PDF.
  • by dattaway ( 3088 ) on Wednesday May 26, 1999 @08:39AM (#1878345) Homepage Journal
    I prefer to keep the AC available. Sometimes a topic can be unpopular and there are times I would not want my name attatched to something due to employment reasons. The AC feature is quite valuable at times. I have seen many good AC posts and most do get moderated up quickly.

    However, in this case, I would not be offended if the knucklehead's IP address somehow leaked out.
  • by Anonymous Coward
    Section 2.3 of the Application ISA Guide says that PA-RISC code will be dynamically translated.
  • Is IA64 a virtualisable instruction set?

    We won't know for sure until the rest of the documentation (for system programming) is out, but the answer is probably no. Eg. in section 3.1.11 the CPUID instruction is described as unpriviledged with no mention of trapping possibilities.

  • ... I am now a complete person for having read it. ;-) But seriously, have the GCC folks and Linux kernel people had advanced access to this? I would like to believe Linux support will be there as soon as the hardware hits the stores. Is Intel sending Linus any test hardware? Not that I am vary worried about Merced being late, I'm probably buying a dual processor alpha anyway.


  • by Breace ( 33955 ) on Wednesday May 26, 1999 @10:37AM (#1878350) Homepage
    Ghee, I can't believe the damn thing is still going to support Real and V86 modes... I wonder for how long we will be wasting transistors to support 8086 programs written in 1984 (which are probably not Y2K compliant and the source is lost so what's going to be left next January anyway?).

    And what about this CPUID reg 2 - Processor Serial Number? I thought we agreed that that was not a Good Thing.

    I though this IA-64 was going to be a 'fresh start' sort of thing. Like rid the old crap. I know IA has never been RISC, but even CISC doesn't seem to apply anymore.

    Now put yer hands together fer Backwoods Compatibility.

  • Could someone go through the vast Slashdot archives and find 2 worthwile AC posts? I don't think they are there, myself....
  • I have ID numbers on almost every important chip on my Sun workstation ...and I manage to live without Big Brother tracking me down.
  • by Anonymous Coward on Wednesday May 26, 1999 @09:37AM (#1878354)
    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)? :-)

  • Great. PDF. What's wrong with html?

    HTML is markup language, not really supporting a good layout mechanism. (CSS allows formatting of text, but is not really designed to allow for complete control of the layout)

    I think it would be about time to move on from pure HTML and not try to incorporate layout into a structuring language. Document structure could still be encoded in HTML, but do an open, simple, text-based PDF-type layout-language-standard on top of that.. (What about PostScript, I guess that's too cumbersome, or not cut out for this job?)

    Granted, documents such as this don't really require fancy layouts, and would be okay in just plain old HTML, but they probably don't have the time to convert all their PDF's into HTML. (The PDF's are needed anyway for printed versions)
  • So by banning AC's we would have lost 1 good post in the last few months? Compared to the troubles they cause, that doesn't sound like such a bad hit to take from the whole cost / benefit analysis side of the question.
  • Using 9 8059 PICs (1 master, 8 slaves), IA-16/32 has always supported up to 64 IRQs (that's not 192, but still, much better than 8/15)). The problem is that nobody ever did this commercially (I wouldn't be suprised if someone did this privately). I guess nobody ever produced a 64 IRQ mobo for two reasons: compatability (the big killer) and, in general, what would you use 64 IRQs for in the first place?

    I can think of some specialist uses for 64 IRQs such as lots and lots of IDE/SCSI/serial/NIC etc controllers (ie big honking servers), but your average user would rarely, if ever, need more than 24-32 (easy to run out with 16, as we all know).

  • by jpick ( 3522 ) on Wednesday May 26, 1999 @08:13AM (#1878360) Homepage
    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.


    - Jim
  • by Anonymous Coward on Wednesday May 26, 1999 @09:53AM (#1878362)
    From what I read, a lot of the benefits in the IA-64 are actually due to better compiler technology -- and binding the compiler and the CPU closer together.

    An example is the "static branch prediction". The compiler will evaluate a comparison for a branch that is always, or never, taken. It'll pass that hint along to the processor to help avoid a misprediction penalty. (Of course, "passing a hint to the processor" means embedding the likely answer in the code.)

    It also mentions that the IA-64 compiler views code with a "wider scope" that in some way increase parallel execution. That point really isn't well developed.

    Another interesting idea is if you have a branch that could either execute "B" or "C", it can signal the processor to execute BOTH forks. Nice for code the has hard to predict branches.

    A great deal of the new features they talk about deal with speculation... speculative data and working the commands in a different order. Some interesting ideas with looping, too.

    I'm not a EE, but this looks like it has some smart features built in that aren't normally thrown into a CPU.
  • I was just reviewing some of the docs that Intel and HP released
    yesterday concerning Merced, and i have read between the lines. Let me
    know if you think i'm off-base with these assumtions:

    1) Merced will max out at 750Mhz in it's first implementation. In the 8
    page Application Developer's Arch Gde, they state that Merced will
    acheive 6Gflops in it's first implementation, and that it is acheieved
    with 4 Multiply-Accumlate units (FMAC). Each unit can do 2 flops, so the
    chip can do 8 flops per clock. 6Gflops, divided by 8 flops per clock
    gives a clock cycle of 750Mhz. And IF the chip could go faster, i would
    think Intel would use those higher numbers. So i think it's safe to
    think that 750Mhz is all that Intel can produce at first.

    2) Since the maximum Gflops rating would include all FMAC units (that's
    the assumtion i'm using), then that would indicate that the Mecrd chip
    will execute 2 LIW instructions per clock. Each LIW word has 3
    instructions, which is not enough to send 4 FMAC instructions, so Merced
    must be able to send 2 of the 128-bit instruction words to the execution

    3) Assuming #2 is right (it might not be), then Merced can perform 6
    instructions (3 in each LIW word) per clock for a maximum MIPS of 4500
    instructions per second (yes, yes, i know how useless MIPS is for
    benchmarking). Or, because of the FMAC units doing 2 ops, 10,000 Mops,
    or 10 billion operations per second.

    I'll be reading the 400+ page Intel doc today, and i hope to find more
    information about memory access. The above rates assume that the chip
    can get enough bandwidth to use all the units above. Just the
    instructions alone mean that Merced needs 24Gbytes/second (256-bits per
    clock, 750Mhz) of cache/CPU bandwidth.

  • "on *it*" may imply a level of cooperation
    that I fear isn't really happening. This,
    combined with the ability to have more eyes
    looking at current work, would certainly make
    it nice (imho) to have at least a cvs read-only
    server with their current work...
  • I don't think the solution is doing away with Anonymous Coward posting (I never really liked the term "Anonymous Coward" anyway). People who'd like to keep their anonymity but still contribute to the general discussion should be allowed to do so.

    However, crap should be dealt with. Rob should be able to track down the IPs of the offending people and contact their ISP. If anything, it's a form of abuse that most respectable ISPs won't allow (the same holds true for newsgroup postings in many cases, so I think the rules can be made to apply to these sorts of things). If the person continually offends and the ISP refuses to come around, Rob can either a) block the ISP (preferred) or b) post an e-mail address where /. users can contact the ISP about said user (this might be as close to a DoS attack that the law allows *smirk*).

    Either way, the system isn't at fault here; abusive users are. Deal with the problem, not the symptom.
  • by Anonymous Coward on Wednesday May 26, 1999 @12:24PM (#1878367)
    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 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, 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, 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.

  • by Christopher Thomas ( 11717 ) on Wednesday May 26, 1999 @09:32AM (#1878369)
    Could someone go through the vast Slashdot archives and find 2 worthwile AC posts?

    There was an excellent example a few months back. In one of the Free vs. Proprietary Holy Wars, an AC posted details of a lawsuit that his company was involved in as a thought-provoking case study. He (or she) would have been fired for doing this non-anonymously.

    From what I can see reading at -1, maybe a third of AC posts are garbage, and most of the rest are at best average, but I see no reason to get rid of AC just because of the actions of a handful of twits. This is the second time that a lone idiot has spammed a thread. A solution that only attacks those twits would be nice.

    Both banning IPs and limiting AC posts from an IP run into the problem of ISPs allocating IPs dynamically, and firewalls remapping users to a single IP address. However, it still might be the best solution (I'm open to other suggestions).

    Or log IP and time for each post, so that Rob can contact the ISPs of abusers and get them LARTed. But that would be a lot of work for Rob.

  • No, I think that you need to stop setting your threshold to -1 if you don't want to see stuff like that.

    Just because there are some asshole ACs out there doesn't justify disabling all AC access. Even the IP/domain limit could be detrimental to the freedom of commentary here.

    What do I see when I bump my threshold to -1? Yes, there are asshole ACs. But the thing that I really see is that Moderators are useful and NECESSARY on slashdot.

    Its like the rockman said. "You see what you want to see. And you hear what you want to hear."

  • Hmmm, just when I was getting worried about warming my basement with my old pII, guess I'll just have to upgrade to one of these.
  • Does this mean that the Linux port can start
    occuring out in the "Open" now? Hmmmm?
  • I have heard, though it is second hand, that Intel is employing two fellows in Ottawa to work on porting the Linux kernel to operate on the Merced platform. Maybe someone else has more information on this? It's from a source I trust, but as I said, I don't have the info first hand, nor a link to it...
  • Good wordplay.
  • You seem to have misunderstood me. Intel had no problem with >16 IRQs, the motherboards had the problem. New style mobos (eg SMP) probably don't have to worry as much about backwards compatability in the PIC arangement.

    That said, I'd forgotten about the SMB boards having more IRQs. Thanks for the heads up.

  • Depending on how expensive the EPIC logic is to compile to, this might or might not be a big boost to Java, etc
    This might also benefit free software alot. With propriertary software you have to supply one version for every processor variant to get the most out of it, while with free software, users can recompile the package themselves.
    BSD ports collection, anyone?
  • 1) I don't think that the G4 will come to the iMac for a very long time.

    2) You are comparing 2 chips that aren't even for sale yet. I'm not sure that i'd feel comfortable comparing the 2002 ford taurus to the 2005 Toyota Camry.

    3) The Merced is not designed in any way to be an upgrade to an existing chip. It is so totally different, and needs a different motherboard. A Mac example would be the 68K to PPC transistion. At that time, you couldn't just change the chip either (but you could get a card that replaced part of the motherboard ASICs).

    4) Motorola is doing ok, just not in personal computers. One could ask why the PPC failed in the mainstream, but if there are only 2 options, MacOS and now BeOS, it just won't be a big seller. Ask instead where Pink, Taligent, Solaris PPC, AIX and OS/2 went. I think that the PPC couldn't take off like it should have without something to run on it.

    5) You are comparing the G4 and Merced, but really they are for very different areas of the marketplace. I don't think anyone is suggesting that the Merced is for personal computer like the G4 is. Merced is for very high end workstations, and honking big servers.

    6) i should tell you that I too am a Mac person. I'll never buy Intel or MS, ever. So i understand some of your feelings, but i just thought that your points were a little off base.

  • I understand that I-64 will be backwards compatible with I-32 code, but will a compiler be able to compile object code that works on existing x86 machines while still exploiting the special advantages of I-64. I'm thinking of something similar to the Macintosh format (fat?) that allows a single codebase to work on PPC and 64K chips.
  • by Anonymous Coward
    Executable file format has nothing to do with the architecture of the microprocessor the executable is designed to run on, but with the operating system.

    Unless Windoze NT, Linux, and other IA-32 (and future IA-64) operating systems begin supporting "fat" type executable formats, executables compiled for IA-64 won't work on IA-32 systems.

    There may also be byte-ordering and little/big endian issues involved, if you are also talking about having data that is IA-64 and IA-32 compatible.

    Personally, "fat" executable formats don't appeal to me. Waste of disk space and file transfer time, if you ask me. Uh yeah, I want to download a 30MB application that will work on IA-64 and IA-32 vs a 20MB one that works on IA-64 (or IA-32) only... NOT. Sure, it might make life easier for Joe lUser, but those people can go buy a Mac if they really want to.
  • Fortunately, it looks like it should be fairly easy to parse IA64 (well, compared to IA32 code, anyway), as all instructions are quadword aligned. This would allow a "scan" and "replace" technique to work well with untrappable instructions.
  • 1) Backwards compatible with x86 for applications not OS. Interrupts serviced in IA64 only.

    There is a x86-OS compatibility mode. How well it works remains to be seen.
  • Yes, there was a paper at ASPLOS last fall talking about doing binary translation, presented by some HP folks. If done right, binary translation is almost as good as native code, and saves silicon space for more useful purposes (e.g., cache).
  • by dmt ( 53976 ) on Wednesday May 26, 1999 @10:48AM (#1878392)
    If you didn't have a chance to catch our Linux/ia64 talk at Linux Expo last week, here
    is a nice summary (including pictures of all the
    slides and the boot screen): onferences/Merced.html
  • I really don't think so, I've heard it used by plenty of people... but not too often from kids in gradeschool... Are you smoking something? Or am I breathing in some fumes making my brain all wacky?

  • not just a P4 or something. It is meant to use a 64 bit operating system and 64 bit compilers. Although it will run 32 bit applications with hardware and not 16 emulation in the kernel like the Windows NX kernel. You could probably run any x86 based OS on it pretty well but if the OS is compiled and optimized for the IA-64 then it will run MUCH better. The new compiling techniques of combining all processes that can be parallel in the code is a great improvement over the chip trying to figure it out in real time. All CPU intensive processes compiled with this technique (which is done when the program is compiled) will run faster than the same program not compiled in this fashion. This processor is also fully RISC (AFAIK), so it would be comparable to a an UltraSPARC or DEC Alpha chip...just much cheaper I hope. The hardware aside, the software will benefit alot from this architecture too. I can think of a few things I would like. A 64 bit linux kernel, a native Solaris environment to the Merced, 64 bit Quake w/ 128 bit AGP bus with it's own multiplier so the AGP and memory bus can run at chip core speed. I just hope AMD can come out with a comparable chip to give Intel some competition in the 64 bit workstation market. I don't see why not, they could easily get some of the Alpha's people working for them.
  • Well, the AMD chip is going to be somewhat crippled by the use of the older IA32 instruction set. The IA64 instruction set is, by design, going to be better suited to lots of parallel execution units. That means that IA64 code will flow a lot faster through the execution units (less bottlenecks). It'll vary depending on what you are executing - but Intel's numbers show about a 40% advantage on average. Of course, this is highly dependent on the compilers doing the right thing.

    Of course, that's only one factor. It's almost impossible to say how it's going to stack up against the competition when it gets released. The competition isn't sleeping...

    Merced is positioned at the high-end, so it should be very fast. It'll probably be quite expensive at first, until Intel starts to phase out the Pentiums.


    - Jim
  • by Anonymous Coward on Wednesday May 26, 1999 @08:18AM (#1878401)
    "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.

  • You can still run x86 code on the Merced. The IA-64 architecture has two compatibility modes:

    1. A 32-bit operating system compatibility mode (basically, the Merced running as a Pentium). I'm not sure what the speed will be on this.

    2. A way to execute all types (Real, virtual-86, and protected-mode) of 32-bit code under a 64-bit operating system (this is similar to Virtual-86 mode under a 32-bit OS)
  • I wouln't be supprised if Intel's using the Newton-Rhapson (sp?) method of calculating 1/sqrt(x). This can be done with a table lookup and a few multiplies and subtractions, acheiving very good accuracy (1 16 bit lookup + 4 mult s + 1 subtraction gives good results for floats). You can then get 1/x by squaring your result.

    Intel uses this technique on the i860, giving results accurate to the last couple of bits.

  • Chill out. Your hard drive and network card both have unique serial numbers that can be read by software.

    The whole PSN thing is ridiculous, ignore it.
  • by Anonymous Coward
    In October of 1993, I bought a 486 DX2/66MHz w/ a whopping 8 MB mem and 340 MB HD. I ended up shelling out $2520 for that machine. I was told by the sales rep and by all the magazines at the time that I would be able to upgrade the processor to a Pentium whenever I wanted. That's why I shelled out the extra money -- upgradeability. But then the day came when the ol' 486 just didn't cut it anymore. Lo and behold, when I went searching for an upgrade processor, there was none to be found. Every place I asked said you couldn't just pop in a new chip. What was that neato lever-socket-thing for then? I wondered.

    After getting burned by Intel -- the OTHER company keeping the entire industry back 10 or 20 years -- I decided I'd had enough. I needed a new computer for college, and I got a Mac. And you know what? My crapola 604e@180MHz can not only be upgraded to a 400MHz G3 (a REAL G3, as opposed to the lame-ass upgrade chips Intel eventually offered), but it will be eventually upgradeable to a G4. How many PCs from early 1997 will be upgradeable to Merced (assuming it is ever actually produced, of course)? []

    Really, the whole Intel paradigm is trash. Why is Motorola doing so poorly if they're desigining much better products? Yes, the Mac OS isn't that great, but that's no reason to harm the beautiful 750 or mmmmm... the 7400. Yum.

    Merced users are going to start feeling dumb when the 800 MHz G4 iMacs (starting at ~$1500, I'm sure) start rolling out and everybody's grandma has a computer that toasts that $20k Intel hulk.
  • Yes they are working on such motherboards. The only thing that needs replacing in fact will be the bios chip and perhaps a keyboard controller. Very sneaky indeed.
  • It's Intel's fault that you didn't look into the motherboard specs to see if it was REALLY upgradable? It seems to me the 486 DX was upgradeable to a Pentium 100...but i could be wrong.
  • by Anonymous Coward
    Section 2.1 shows a "IA-32 virtual mode". There aren't details since these will be in the system programming guide (as for Pentium II). But this probably means that it will be easy to write virtual machines for IA-64. Isn't it grat :-)

    Instructions (jumps) for going back and forth between IA-32 and IA-64 are given too, which is nice to mix old/new code.

  • There should not be any extra load from reverse ip'ing -- the IP address of the connection is available for free. The only addition is a write to a log file, which isn't very expensive.

    Now, if he had to do a reverse-dns lookup, that would put extra load on the system.
  • >And what about this CPUID reg 2 - Processor Serial Number? I thought we agreed that that was not a Good Thing.

    Like everyone else has said, lots of parts in computers have serial numbers, especially on higher level hardware. I've got no real problems with that.
    It's Intel's marketing, proclaiming it a way to track users and secure e-commerce, that is not a Good Thing.

  • One of the things that is interesting about the IA-64 is that the compiled code to be run on it is highly sensitive to the particular architecture of a given chip. Intel's docs say that the architecture is highly scalable, that they'll be able to add new execution units, etc., quite easily, but they don't mention that the choices an EPIC compiler would make would change quite a lot depending on the physical chip details.

    As a consequence, we might see things like Just-In-Time compilers become more significant than they already are, since they could make those decisions when code is executed on a particular chip. Depending on how expensive the EPIC logic is to compile to, this might or might not be a big boost to Java, etc.

  • So Intel's on a nice roll with the IA32s being called Pentium (some number).

    Man, I sure hope they decide to come up with a new brand for IA64!
  • While it's true that executing both paths following a branch means work will be thrown away, predication relies on the assumption that wasting some execution units to execute unnecessary code will be faster than executing into one path, finding out it is wrong, flushing the pipeline and starting all over back at the branch. The idea is to predicate hard-to-predict branches.

    Researchers have also toyed with the idea of dual execution, which is a similar idea, only it is done dynamically by the hardware. A simultaneous multithreading machine might do this, for example.

    Predication can also be used to eliminate the loop prologue and epilogue when performing software pipelining, resulting in smaller code size.

    The slides at the site give some good examples of how to use predication.

  • With merced being delayed and delayed I really don't see how Intel can expect to take ANY of the really high end, fault-tolerant server market away from the current major players like the alpha, sparc, and the hp pa-risc.
    If I am right even the *estimated* merced specs are about in line with what you can get in a decent 21264 alpha right now. Unfortunatly I'm not as familiar with other architectures besides the alpha, but that is the current performance leader so its definitly the best to slam intel with. :)
    If everyone is going to have to port thier apps to ia-64 with merced and all that I don't see why they might just not port to alpha at the same time. I don't know much of anything about the actual porting of apps so please correct me if I'm very wrong. From what I have heard the biggest deal in currently porting from x86 to alpha is the move from 32 to 64 bit with data structures and the such. If, as it looks now, most of the merced work is done in the compiler hence everything will need to atleast be recompiled if not re-coded, then this could be a key turning point in the popularity of the alpha. If everything is going to 64bit why not go to one of the fastest, and definitly more stable 64 bit processors, with no backward compatibility crap and built for nothing but pure speed. The only problem I see currently for the world dominance by the alpha is the price, though it seems compaq is starting to try and fix that part too. By no means is a 533 alpha system cheap, but its not too bad when you consider the performance of what you are getting.

    But off topic i have gone. Hopefully compaq can position itself in a position to take advantage of the fact that millions, if not billions, of lines of code will need to be re-written and make sure that code is also ported to the alpha. This could be intel's worst mistake yet, trying to force people to change platforms from one where they all but wrote the book to one where they are at a distinct disadvantage.

    I'm not the devil's advocate, my box just runs at 666
  • by Anonymous Coward
    Since they are going for the whole nine yards with IA-64, can we have *please* some advances in the rest of the processor (like eg. interrupts?).
    Come'on, even 68000 has 192 interrupt vectors with 5 interrupt levels...
  • Unfortunatley, setting threshold to 0 still shows whatever that crap was, thanks to some moderator having raised several posts back from -1 to 0, and it having stayed at 0 for several minutes. Moderation gone wrong to say the least.
  • Does this mean that the Linux port can start occuring out in the "Open" now?

    Start, perhaps, but not finish. The document in question is the IA-64 Application Developer's Architecture Guide, which appears not to give all the details needed for low-level OS programming; it says:

    Full details of the IA-64 programming environment including the system architecture and software conventions will be provided in IA-64 Programmer's Reference Manual to be available later.

    and some of those details will presumably be necessary for OS kernel work.

  • > An example is the "static branch prediction".
    > The compiler will evaluate a comparison for a
    > branch that is always, or never, taken. It'll
    > pass that hint along to the processor to help
    > avoid a misprediction penalty. (Of course,
    > "passing a hint to the processor" means
    > embedding the likely answer in the code.)

    Though the white paper isn't clear on this, they aren't talking about static branch prediction as a chip feature. The improvement comes when the compiler can't tell which path will be taken.

    In this case, on a low-end PowerPC, the compiler will guess. For example, for a loop, it always predicts the loop will be taken. For the high end PowerPC, its hint is used as the initial prediction (weakly predict taken or not taken, see below).

    The high-end PowerPC does dynamic branch prediction. It has a LRU cache of 2 bit values for the last N branches taken. 00 means strongly predict not taken, 01 is weakly predict not taken, 10 is weakly taken, and 11 is strongly taken. Each time a branch in the cache is hit, its value is incremented if actually taken, decremented if not.

    In both of these cases, branch prediction determines the path that will be speculatively executed. I understood what made the IA-64 special was that it executes *both* paths speculatively and then throws away the changes from the path not taken. In other words, it doesn't do branch prediction at all.
  • Maybe HP plans on using software emulation?

    Could be; if I remember correctly, they handled the transition from the 16-bit stack-machine HP 3000's to the 32-bit PA-RISC HP 3000's by doing binary-to-binary translation, and they may plan on handling the PA-RISC to IA-64 transition in the same fashion.

  • by Anonymous Coward
    Fairly RISCy. Just a quick summary from my reading:

    1) Backwards compatible with x86 for applications not OS. Interrupts serviced in IA64 only.

    2) Fast register stack & 128 registers. Will be fast for call/ret. But no memory stack.

    3) Nice FP dot product & single precision parallel calcs. But no division/sqrt/exp/trans. Approximations via 256 ele lookup-table!

    I suspect this chip will underperform P6/K7 at x86, and may underperform 21264 at FP. Then it will need strong OS/app support. Linux?

    -- Robert
  • by Anonymous Coward
    Just how fast is this thing going to be. Do you think it'l be a serious contender against Mot/IBM G4, or perhaps the latest Alpha?

    Sounds exciting, wonder what AMD is going to do about this. Shame AMD will probably be the one keeping the x86 arch alive, as much as I like its price/performance ratio, we need to move on :).

    Just my 3.597349574937502 cents
  • by Anonymous Coward
    I won't be buying any Intel cpu till they remove the psn.

    Die psn, die!
  • Intel has spent a lot of time doing this thing right. I bet you will be enjoying your favorite OS on the oddles of power Merced will be delievering. Given that it will be only affordable for enterprise needs but the old Intel trickle down economics will have us mortals EPICing in no time (Can you say CeleronA >= P2.) For your reading enjoyment. I liked this CMP Article [] as a nice intro / gossip on Merced.
  • So basically this chip is leaving the x86 instruction set, right?

    Well I have seen alot of comments about how they (/.'er) wished there were other competitors in the x86 field and I just wanted to point out this link to you guys, which I sent up about 11am, but hasn't been posted.

    Rise Technologies []
    "Windows 98 Second Edition works and players better than ever." -Microsoft's Home page on Win98SE.
  • Yes, having a board that will accept either alpha or K-7 would be nice. Having a board that will accept BOTH at the same time would be nicer. I'd really like to get the speed of alpha for native processes, without losing the ability to run solitair in WINE. (what else does anyone do with their time anyway?) I'm sure there are more things that can be done too.

    I hearby disclaim any acknologiment, monitary or otherwise from any person or other entinty using this idea.

  • I can think of a few things I would like. A 64 bit linux kernel...

    Already got one. Alpha and SPARC64 run it.

    Making Linux run well on Merced isn't likely to be very hard by itself. Making GCC work well with it will be much harder (with emphasis on "well"--a half-assed job wouldn't be hard).

  • If you want to say "No to ACs" the proper procedure involves a flick of the wrist and a few button-clicks on the mouse. I know it's odd, most places you say "No" with your mouth, but here on /. you say "No to ACs" by setting your threshold to 1.

  • what would you use 64 IRQs for in the first place?

    Good question. I may be missing something, but, as far as I can tell, there's no hardware reason why an OS couldn't let multiple PCI devices share the same IRQ (heck, I did much of the PCI support for an OS that did so on hardware not too far from a somewhat fancy PC, namely NetApp's Data ONTAP on the F3xx and F2xx filers).

    Perhaps many PC OSes don't support that, but, if so, perhaps those OSes will get fixed for IA-64 (although if Windows 9x is one of those OSes , it may not get fixed, so people who have to reboot their shiny new IA-64 workstation to run some games might be screwed).

  • I don't want AC posting to go away entirely, but if it ever does, it only takes a few minutes to create a throwaway user account using a throwaway freemail account. The effort would probably be too much trouble for some little dweeb who wants to flood a thread with garbage, but worthwhile if you were posting priveleged info or something of the sort. This isn't an optimal solution, but it'd be nice to think that Hotmail was useful for something.
  • Why don't you ban AC's by setting your threshold to 1, and the rest of us won't miss out on that one good post? You have the means at your disposal to solve your problems, but you'd rather complain. Most people wouldn't even have known about the AC situation with this article if you hadn't brought it up and been the highest ranked article for a while. I normally wade through all the -1's, but you don't have to if you don't want to. If you set your threshold low, you have to take the good with the bad.

    Of course, an AC could create a login but not provide any public contact information in their user info if they are posting from work. This is what I have done. Only Rob (and my hairdresser) knows for sure...

  • by Anonymous Coward
    Check out page 3-10 for an unprivilidged CPU ID register.

  • Howdy!

    The only reference to speed I could find was the aim that it "will be 3x faster than a PIII". The basis for this is that it will apparently do 6 gigaflops as oppossed to 2 gigaflops for the PIII.

    If I was cynical I'd say that this is probably the best spread (3 times!) they could get for a press release and that gigaflops != SPEC numbers.

    If the Merced really has an FPU 3x faster than a PIII that means what? 45SpecFP? 60SpecFP? 2nd quarter of next year? Don't Alphas do that _now_?

    Anyone else see any performance numbers?

  • And as a student here pointed out, you can compile some of your routines in IA32 as a poor-man's program compression mechanism. ;-)
  • by jpick ( 3522 )
    I thought the Merced was supposed to be compatible with the PA Risc instruction set? I don't see any mention of that in the document (at least, not yet). Maybe HP plans on using software emulation?


    - Jim
  • >Executable file format has nothing to do with the architecture of the microprocessor the executable is designed to run on, but with the operating system.

    Well, saying that executable format has nothing to do with processor architecture(s) seems a little strong. The two do relate in quite a few ways.

    >Personally, "fat" executable formats don't appeal to me

    Me neither. One alternative would be to distribute code "compiled" for some sort of VM and then either interpret it or compile it (user choice) as is done for Java. This is a special case of the more general approach tried by ANDF (Architecture Neutral Distribution Format, for you younger folks) and similar efforts peaking around ten years ago. Some used virtual machines, some encoded parse trees so you could do more global kinds of optimization while compiling ("installing") the result, etc.

    There are some really big-time hairy issues involved in all this, but I've never been convinced that the non-adoption of ANDF was really due to technical failings so much as end-user ignorance of the benefits. I would love to see some of these ideas brought back.
  • I thought one of the advantages of PCI was that it did permit multiple devices to share an IRQ...
  • A couple comments on what I've seen thusfar:

    1) Contacting the ISP of the obnoxious AC is inappropriate, no matter what he or she posted. The 'anonymous' account is offered under the condition of anonymity for whatever purpose - I seem to recall a thread where someone posted anti-minority and Nazi-like propoganda. In bad taste? Yeah. Something Rob should track down the person for? No. The point at which you start doing that, you are no better than they.

    2) Spoofing. Everyone knows what it is, everyone knows how to do it. What if the logs show the comments coming from ''? What do you propose doing at that point, contacting the upstream provider to yank's access? I hope not.

    3) Moderators are here for a purpose. That purpose happens to be knocking inappropriate messages below a certain threshold so that the majority of users do not have to see them.
    Rob should be the only one with a complaint here, folks - somebody just inflated the size of his message database by about 5k (whoopie!).

    4) This is a _message board_. Come on folks, it's
    not like somebody just threw rotten eggs at your house or something. Settle down, take a deep breath, and work it out.

  • by mistshadow ( 35753 ) on Wednesday May 26, 1999 @11:32AM (#1878453)
    You are correct in that the execution speed is halved, but there are two misconceptions in your reasoning:

    1. The execution speed is only "halved" (i.e. half the parallel processors are doing something that will be thrown away) until the test completes executing. How long this is depends on the architecture. The way they do their speculative execution, they can keep more of the processor busy at any given time. Sure, you throw out a lot of your work, but you rarely have to start over. What kills execution time is pipeline stalls, which this avoids.

    2. You seem to be implying that this is a bad thing. In a "perfect processor" it might be, since you have some execution units doing stuff that won't be used, but compared to other current architectures, this design is a win, since you avoid the problem of mis-predicted branches, which are expensive.

    Compare what the IA-64 does to what the PI/PII/PIII do currently: The processor guesses which side of a branch it should take, and starts speculatively executing just that branch's instructions. When the test completes, either:

    1. The prediction was correct, and everything moves along as normal

    2. The prediction was incorrect, everything is thrown away, and it goes back to follow the other branch. This is very expensive. (on the order of 10-30 cycles, if I remember correctly. The whole pipeline has to be thrown away.)

Loose bits sink chips.