Slashdot Mirror

← Back to Stories (view on slashdot.org)

Merced Architecture Specs

Posted by ryuzaki0 on from the opcodes-and-registers dept.

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.. "

27 of 114 comments (clear)

  1. Re:Moron Anonymous Cowards... by dattaway · · Score: 3

    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.

  2. Re:PA Risc by Anonymous Coward · · Score: 2

    Section 2.3 of the Application ISA Guide says that PA-RISC code will be dynamically translated.

  3. I laughed, I cried... by Izaak · · Score: 2
    ... 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.

    Thad

    --

    The Bolachek Journals

    1. Re:I laughed, I cried... by jpick · · Score: 5

      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

    2. Re:I laughed, I cried... by James+Manning · · Score: 2

      "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...

      --

      Various ramblings
    3. Re:I laughed, I cried... by Anonymous Coward · · Score: 5

      "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.

  4. The good news: IA64 sports MMX! by Breace · · Score: 3

    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.

    Breace.

  5. Where is the rest? by Anonymous Coward · · Score: 5
    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)? :-)

    1. Re:Where is the rest? by Anonymous Coward · · Score: 5
      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.

  6. IA-64 Comments: The Compiler / Financing by Anonymous Coward · · Score: 3

    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.

    1. Re:IA-64 Comments: The Compiler / Financing by jonabbey · · Score: 2

      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.

      --
      - jon

      Ganymede, a GPL'ed metadirectory for UNIX
    2. Re:IA-64 Comments: The Compiler / Financing by David+Greene · · Score: 2
      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.

      --

    3. Re:IA-64 Comments: The Compiler / Financing by mistshadow · · Score: 3

      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.)

  7. Re:Moron Anonymous Cowards... by Hrunting · · Score: 2

    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.

  8. Re:Moron Anonymous Cowards... by Christopher+Thomas · · Score: 3
    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.

  9. forward binary compatibilty by copito · · Score: 2

    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.
    --

    --
    "L'IT c'est moi!"
    1. Re:forward binary compatibilty by Anonymous Coward · · Score: 2

      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.

  10. Linux/ia64 being done already [was: Re:Linux/IA-64 by dmt · · Score: 4

    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):

    http://marc.merlins.org/linux/linuxexpo99/Day3/C onferences/Merced.html

  11. Re:How does it stack up to other chips by jpick · · Score: 2

    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.

    Cheers,

    - Jim

  12. Re:Quick summary: FDIV approximated. by Bill+Currie · · Score: 2
    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.

    --

    Bill - aka taniwha
    --
    Leave others their otherness. -- Aratak

  13. Merced and the alpha by cale · · Score: 2

    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

  14. This isn't the full IA-64 instruction set by Guy+Harris · · Score: 3
    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.

  15. Quick summary: FDIV approximated. by Anonymous Coward · · Score: 2

    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

  16. More Cannon for the Fodder by millerkj · · Score: 2

    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.

    --
    ---- Now I am done ---- Shh
  17. CPU ID is still there. by Anonymous Coward · · Score: 2

    Check out page 3-10 for an unprivilidged CPU ID register.

  18. PA Risc by jpick · · Score: 2

    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?

    Cheers,

    - Jim

  19. Some friendly advice by Olorin · · Score: 2

    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 'www.hp.com'? What do you propose doing at that point, contacting the upstream provider to yank hp.com'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.

    Olorin.