Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
AMD

AMD's 64-Bit Chip 519

Posted by CmdrTaco from the lookit-all-them-bits-in-there dept.
EyesWideOpen writes "AMD is set to release a 64-bit chip early next year which will be completely backwards compatible with the Athlon line. The current 64-bit offering from Intel, Itanium, is an entirely new chip that has no backwards compatibility with its x86 line of chips (from the 8080 chip to the Pentium IV) and is designed only for high end servers. AMD's solution to this problem is the Opteron chip (product info) which will be in servers, desktops and laptops. Here is a wired article."
This discussion has been archived. No new comments can be posted.

AMD's 64-Bit Chip More

AMD's 64-Bit Chip

Comments Filter:

  • Wow (Score:3, Funny)

    by krogoth ( 134320 ) <slashdot.garandnet@net> on Monday July 22, 2002 @06:56PM (#3933691) Homepage
    I've seen duplicate stories, but this beats them all! :)

    • Re:Wow (Score:5, Funny)

      by unicron ( 20286 ) <unicron AT thcnet DOT net> on Monday July 22, 2002 @07:01PM (#3933717) Homepage
      Somewhere a Delorean reached 88 miles an hour to get this story to us.
      • Hmm I didn't see this story originally. The last thing I remember was a guy named T telling me to look directly into an chrome vibrator. There was a flash and... uh. wow, what an exciting story! I have an urge to subscribe though...
    • people complain about slashdot rerunning stories. have you looked in the newpaper recently? There are full of repetitions and dupilicates, sometimes much more frequently. How many times have you seen violence in the middle east or northern ireland? How many times can you read about some crappy Martin Lawrence movie? All the slashdot editors are doing is trying to keep up with the newspapers.

  • Breaking news!! (Score:3, Informative)

    by _typo ( 122952 ) on Monday July 22, 2002 @06:58PM (#3933702) Homepage
    Slow day, huh?
  • Backwars compatibility isn't always good, sometimes you should forget the past and move on.
    Why would we want to remain compatible with x86 and all it's shortcomings ?
    • Perhaps you might want to look up the history of OS/2 -- which was mostly backwards compatible with the general expectation that developers would write and rewrite "new" apps directly for the OS.

    • Re:Backwars compatibility (Score:5, Insightful)

      by zmooc ( 33175 ) <zmooc@[ ]oc.net ['zmo' in gap]> on Monday July 22, 2002 @07:22PM (#3933837) Homepage
      Why would we want to remain compatible with x86 and all it's shortcomings ?

      3 reasons:
      1. Software is written in way too many different languages to make porting compilers even remotely possible. Therefore: no software.
      2. Most software is closed source so you'd have to pay for new software (which isn't even available because of 1.)
      3. There's no OS. Sure, you can port most Open Source OS's in a fairly short time, but there's more than Open Source...

      It's just not worth the trouble from a commercial point of view as long as most software still is closed source. This is only viable for vendors that sell hardware AND operating systems at the same time: Apple, Sun etc. and even they will hesitate to do so because they don't want to force their customers to pay for all their 3rd party software again...

  • MS Support (Score:2, Informative)

    by medeii ( 472309 )
    I'm pretty sure Microsoft's supporting AMD's x86 tech, rather than Intel's 64-bit offering.

    http://www.amd.com/us-en/Corporate/VirtualPressR oo m/0,,51_104_543~19906,00.html

    Kinda weird to see AMD's technology being chosen over "the leader's," even when it is so obviously superior in terms of compatibility. Never thought I'd see this day, I guess. ;)

    • Re:MS Support (Score:2, Interesting)

      by JPriest ( 547211 )
      You also have to consider that Intel has not yet decided to release a 64 bit desktop chip. When they do, you can be sure there will be Microsoft support. Intel's first 64 bit desktop chip will probably be largely based on the Itanium III, it will also probably be very fast.
    • Microsoft has said they will be supporting x86-64, but they have not said they will not support a 64 bit desktop chip from Intel. In fact, they did support the origional Itanium.

      Itanium is targeted for the $20k+ server market- not really Microsoft's strongest segment. Itanium is not even designed to compete with Hammer. And there will be plenty of server OS's available for Itanium2.

      If/When Intel decides to make an entry into the 64 bit desktop market, I think you can rest assured that Microsoft will support it also.

  • Stability (Score:2, Interesting)

    by Quantum Singularity ( 594841 )
    Running programs in a hybrid 32/16 bit environment puts a serious strain on the Windows OS: It crashes. Pure systems do not crash as often. I really wonder if the problem will be magnified in a 32/64 bit environment?

    • Re:Stability (Score:2, Informative)

      by Anonymous Coward
      No, because the problem in Windows wasn't moving from 16 bit to 32 bit, it was moving from cooperative to preemptive multitasking.

  • Henry Ford set to release Model "A" (Score:4, Funny)

    by A nonymous Coward ( 7548 ) on Monday July 22, 2002 @07:03PM (#3933728)
    Ford Motor Co. is set to release today a new car, the Model "A", based on the award winning and famously popular Model "T". The new Model "A" is backwards compatible with all previous 4 wheel gasoline powered Model "T" cars produced by Ford and its competitors, and can run on the same roads as them.

  • I've been waiting for these bad mama jamas. I must have spent a week trying to install OS X on my Athlon XP. I couldn't believe how rude the tech support at Apple was, even though I tried to switch. I thought that Quartz would make the windows framing my porn look pretty, but I haven't had a chance to see. I hope this 64 bit CPUs change all that. I used to write 64 bit assembler programs all the time, but they never compiled and linked right. I blame the makers of GeOS, that had to have been the worst IDE I've ever seen for ASM.

  • Well, I suppose your reaction to this depends on your personal product loyalty (or possibly lack thereof). Basically, a CPU will inherently run slower if it is backwards compatible with a completely different architecture. What AMD needs is a chip that solely does 64-bit ops, like the Itanium. Now, I realize that this would require all programs to be recompiled/rewritten, but isn't that what PDA's require anyways? And I'm sure the conversion from 32-bit to 64-bit is a lot easier than 32-bit to Async (could someone familiar with that process verify/refute this?).

    This is, in essence, what I'm saying: AMD should come out with 2 64-bit processors, only one of which natively supports 32-bit apps. Why? Otherwise Intel will absolutely rip AMD to shreds in the benchmarks test. Being a loyal AMD user, I don't want to see this.

    • "But it has more bits", says my friend as the reason his Play Station 2 is better than my PC graphics. He doesn't understand that my computer, a 32 bit instrument, actually has a 128 bit graphics card. He also doesn't understand the purpose for all those bits. He just thinks the more of those bits you have the better.

      Intel may do better in the benchmarks; however, AMD will offer you a "64 bit computer with a SPECIAL 64 bit version of Windows." When the average user goes to buy a computer they don't check benchmarks. The key to selling these new units will be the more stuff appeal (and the better price of AMD). I want the computer with more bits, don't you :o)

    • No... a 64bit chip doesn't have to be 'slower' (Score:5, Insightful)

      by Coventry ( 3779 ) on Monday July 22, 2002 @07:38PM (#3933931) Journal
      A properly designed 64-bit CPU does not need to 'run slower' to run 32-bit apps. AMD came up with a simple solution to the 32-bit limitations of X86 code: they added a new 'mode' to the processor to run 64-bit binaries. when this mode bit is set (similar to the old Real and and Protected modes of X86 chips), the chip utilizies the full 64-bit-wide pathways for data and cacluations, when this bit is not set, only the lower (or is it upper? AMD isn't saying...) 32-bits of the pathways are used. The same exact logic units are used for all 32-bit and 64-bit calculations, only the bit-depth precision changes. Thus if it takes an ADD instruction 16 cycles to add two registers and store the results in a third register, it takes 16 cycles reguardless fo whcih mode the processor is in. Of course, AMD also added an extra 8 registers for use in 64-bit mode... very useful.

      The itantium does not get the majority of it's speed from being 64-bit - this is a common mistake people make. It has a _very_ different design and instruction set - EPIC - which places the burden of parallel instruction determiniation on the compiler. Basicly, they used the oldest software refactoring trick in the book, but on the whole processor design: they examined the amount of time spent executing, and looked for the bigest runtime performance-hit that could be moved from a O(n) to a O(1) penalty by simply moving the calculation. In this case, modern processors spend a great deal of time trying to handle multiple instructions at once, which may or may not be parralellizable (is that a word?) - thus the processor has to figure out, on the fly (in a P4, for example), if it can execute the next four add instructions in parallel, or if they are interdependant and cannot... By placing the burden of parellelism determination and instruction scheduling on the compiler, intel made the compiler writer's job much harder, but at the benefit of increased performance.

      Oh, and most PDA processors are much more traditional, and thus don't require complex compilers like the itanium, so actually porting a compiler (or an assembly-lang app) to a PDA from x86(32-bit) is easier than creating one for the EPIC architecture.

      And yes, I know the above is an oversimplification, and Intel and AMD both did a lot more, in a lot more detail, on thier 64-bit chips.

      Oh, and I think the next few iterations of itaniums _will_ beat the AMD 64-bit chip on bechmarks. But not by a landslide.... And with the differences in price (EPIC chips are Expensive... capital E) the AMD chips will win the hearts of many and be the performance-price ratio king. And who wants to pay 3 times as much for 20% more performance?
      • "AMD came up with a simple solution ... when this mode bit is set ..."

        I'd note that this is not a new solution, and possibly not a desirable one. The book "The Soul of a New Machine" describes the engineering effort at Data General c1980 to develop a new mini computer. I think it was a 32 bit design, and needed to be backwards compatable with the older 16 bit design. The chief engineer insisted that the compatability *not* be done by a 'mode bit'. I can no longer remember what the objections to a mode bit were. Can anyone comment?
        • Purely 'looks', just like a four cylinder car would look strange with big nose on it to fit a six cylinder engine in it. (Something GM did in Australia to the Vauxhall Viva to create the Torana. It was a very fast car, if you didn't need handling).

          In practice, you can always work around the kludge with software, and then don't have the problem of software compatibility, just because the engineer threatened to throw a hissy fit.

          • Better still, the Porsche 904, originally shipped with a 2 liter 4 cylinder engine, then modified for the 6 cylinder, and again for the 8.

            Come to think of it, the 914 also originally ran with a 1.7 liter four, 2.1 liter 6 (for the 914/6), and some examples were made with the flat-8 (minus the rear luggage compartment, of course!) - but both of these cars had no modification to the exterior bodywork to accomidate these different engines.
        • The guy insisting on not having a mode bit was Tom West, who was the head of the project (not sure if he did any engineering day to day). The reason was that any 'compatibility mode' not used by new software in the 'new mode' is a candidate for one day being removed. West (and presumably Data General) considered this a bad thing for customers, because it would mean old software had a limited lifetime. This was in direct contrast to Digital (DEC), who had introduced the VAX 32-bit architecture with a 'mode bit' to support PDP-11 code in compatibility mode.

          AMD's approach is very like DG's, and also like Intel's approach from the 8086 to the Pentium 4 - don't allow the legacy software to become dependendent on a compatibility mode that is not used by new software, because the software base is a critical asset. Intel's move to the IA-64 architecture is a key opportunity for competitors to target its installed base - if you are going to have to port your software, why not port it to some other chip?

      • Thus if it takes an ADD instruction 16 cycles to add two registers and store the results in a third register, it takes 16 cycles reguardless fo whcih mode the processor is in.
        Case and point. If a 64-bit processor had a 64-bit ADD instruction that takes 16 cycles to complete, a similar 32-bit ADD instruction (assuming the addends and sum are within the 32-bit range, which would be the case if performed on a strictly 32-bit app) would take approximately half (8) the amount of cycles to complete. Thus, if the 64-bit proc was running a 32-bit app with a clockspeedXmultiplier of 1600MHz, it would finish the task at an apparent rate of 100MHz, whereas an equivalent 1600MHz 32-bit proc would finish the task at an apparent rate of 200MHz.

        Oh, and I'm not talking about any extras on the chip such as different queueing algorithms or assemblers. That wasn't my point.

        • Case and point. If a 64-bit processor had a 64-bit ADD instruction that takes 16 cycles to complete, a similar 32-bit ADD instruction (assuming the addends and sum are within the 32-bit range, which would be the case if performed on a strictly 32-bit app) would take approximately half (8) the amount of cycles to complete.

          That depends on the design of the adder. Full adders, half adders, ripple-carry adders, and other types of adder exhibit different behavior as the word length is increased.

          Consider: the upper 32 bits can be added in parallel with the lower 32 bits, and a correction step added in the case where the lower 32 bits overflow into the upper 32. That won't take twice as long as a single 64-bit add, though it will require more logic.
        • "it takes 16 cycles reguardless fo whcih mode the processor is in."
          br. Even with the typo left in, its fairly obvious my meaning here - a 64-bit add takes as many cycles as a 32-bit add in the 'hammer' design by AMD - the same Adders are used for each - just in one case (32 bits), half the bits involved are ignored.
      • I think the parent's parent was half right. It's not that 32-bit compatability is a huge drag, it's that x86 compatability is a huge waste of transistors if you don't need it, or are willing to get the x86 compatability from emulation.

        One of the big problems with the x86 instruction set is the multiple width instructions that need to be partially decoded before their length is known, this makes the decoding step partially inherently serial.. very hard on high performance superscalar architectures... Without the P4's translation cache or the AthlonXP's three decoders (two of which must always wait for the one to partially decode their op before they know where to start), the ALUs would get instruction starved pretty quickly.

        I'd be darn happy if I could get an x86-64 chip with the x86 decoder replaced by a decoder for instructions that are much closer to the chip's internal instruction set. The only software on my machine that I didn't apt-get is the Sun JVM, so if the chip were even mildly popular, there's a good chance all of the stuff I use would be ported. Without the x86 royalties being paid to Intel (parts of the instruction set are patented) and without the extra chip realestate (==chip cost) and work required (== heat and power consmption) for x86 compatability, I'd be much happier. Clock rates might not go higher, but the chips might be able to dipatch more instructions per cycle while using less power and fewer transistors.

        Itanium and "majority of its speed" in the same sentance! Hehe... Why the heck didn't they give the Itanium a full FPU instead of causing some of the floating point instructions to raise a floating point software assist exception for the kernel to handle? (This is a big performance kill for FP, and also the reason why at least some FP operations are not permitted while running in kernel mode in the Linux ia64 port.) Register windowing was also a bad idea. It doesn't surprise me that the thing runs so hot and slow and uses so much realestate. They added some whiz-bang features (register windowing, anyone seen it used effectively in SPARC?) instead of some useful ones (like a hardware-only FPU).

      • I'm just curious if Intel will take the spare bit that AMD will have to use to indicate the new modes, and then allocate it to something else in the Pentium 5?
    • Just because a chip is backwards compatible, does *not* mean that it is slower. For starters, the new x86-64 is a superset of the x86-32. This means that 64-bit apps can take advantage of additional registers, better (read: not stack based) floating point, etc. In other words, it makes no sense of AMD to have a "pure" 64 bit proc and a "compatible" 64 bit proc. The "pure" proc would not gain anything from ditching the 32bit ompatibility (other than fewer transistors, which would cause the chip to run a bit cooler/suck less power). Unless of course, the "pure" proc and "compatible" proc had different instruction sets, which would go against their whole strategy.

      In other words, newer does not necessarily equal better (for some definitions of better).

      It may have been better for you to construct your post in the form of a question ("all other factors (bus speeds, memory latencies, process technology, etc) being equal, what advandages/disadvantages does x64-64 have over IA64?").
    • Basically, a CPU will inherently run slower if it is backwards compatible with a completely different architecture.
      >>>>>>>>
      You do realize that most of the major RISC chips are backwards compatible with older archs. UltraSPARC (64-bit) is backwards compatible with SPARC (32-bit). There are several MIPS ISAs as well.
  • If Windows runs on Itanium and not on AMD, that's the end of AMD.
    • The Mac shows how a great system with all the best features can not be worth a damn if they don't have the products to back it up. Think of the tens of thousands, the hundreds of thousands, of small 32 bit programs are out on download.com right now. You can't use one of them on the itaniam. No kazaa, no winamp, no aim, no small shareware/freeware apps, and no GAMES!!! If Intel thinks they are going to get a desktop switch over to 64 bit in the next two years b/c they have a faster chip then they must have accidently hired some old Apple employees.

      And I have no clue if the mac OS is more stable, faster, etc. But I'm just going from what mac people tell me :)
      • Who the hell needs a DESKTOP system to be 64 bit? How many people's desktops have (and actually use) 2 gig of ram (or more) right now? Or will in the near future? The desktop NEED for 64 bit systems is way WAY off. Servers yes, desperately, now. Desktops... no. Games... no. I even do some fairly heavy photoshop work including posters on our 32, 48 and 60in printers, but I have rarely needed more than 512 meg for even that.
      • Think about the thousands of small 32 bit programs out on debian.org (or gentoo.com or redhat.com) right now. I can just recompile any of them on whatever proc I want!
    • Up until 4.0, NT was multi-platform. Hopefully M$ had enough foresight to keep the code portable just in case they ever wanted to be multi-architecture again. As much as I hate the MS monopoly, I dislike the "everything is x86" mentality more. Linux ia64 sets the CPU up to be big endian, right? And Win ia64 sets it up as elttil naidne?

      <OT>
      BTW, other than being able to use a single integer load opcode and still being able to increase register size, what are the advantages of elttil niadne architectures? (Obviously, programmer familiarity is also a factor, but the switch isn't that bad.) Network byte order is defined as big endian, so switching everything back and forth stinks. (I know, X11's solution is beautiful, but that's beside the point.) I noticed that both Itanium and XScale CPUs have the endianess as part of the CPU state. MIPS machines come in both endianesses. So, why do we come out with new architectures that have the little-endian option? (Obviously x86 compatability reuires it in this case.) MIPS comes in mips and mipsel flavors. Can you get a PPCel chip? PaRISC and SPARC are big-endian only, and I think the IBM POWER family are as well. Giving the chip the option of ether endianess adds complexity and transistors, although not many.

    • Bill (Gates) announced that Microsoft(tm) would support Opteron. Jerry (Sanders) gave nice pro-Microsoft(tm) testimony at the anti-trust trial. Funny how Microsoft(tm) seems to encourage competition in the x86 market. Oh well. I'm not complaining if it keeps AMD and the x86 market viable.

  • Since when is the 8080... (Score:5, Interesting)

    by ncc74656 ( 45571 ) <scott@alfter.us> on Monday July 22, 2002 @07:19PM (#3933821) Homepage Journal
    ...considered part of the x86 family? The first processor in that lineup is the 8086. I think the 8086 might've been source-code-compatible (to some extent) with the 8080, but you can't take an 8080 binary and run it on any x86 processor (emulation doesn't count).
    • Whoever submitted the article probably meant 8088, not 8080. The 8088 was a cheaper version of the 8086. As someone else pointed out, it used an 8-bit bus interface instead of a 16-bit one, similar to how the 386sx used a 16-bit bus instead of a 32-bit one. It is still code-compatible. The 8088 was used in the original IBM PC.
  • In other news... Pentium IV processors can now use DDR memory, you can now get dual-processor Athlons systems, and the Intel Pentium-3 processor has new instructions that will allow it to "revolutionize your internet experience" dubbed "SSE"

  • 36 years early! (Score:3, Funny)

    by ajrs ( 186276 ) on Monday July 22, 2002 @07:44PM (#3933968) Homepage
    my 800 MHz AMD is still doing the job. I don't really need a 64 bit chip until 00:00:00 UTC, January 1, 2038.
  • Opteron, PentaGONE, opteron, pentaGONE ...

    nahhh, gotta be a coincidence.

  • Staggering quote from the Wired article, effectively rendering the author's opinion moot:
    • "While the first 32-bit processor came out in 1995, the average PC used 1 MB of memory, so 4 GB was both unaffordable and generally not needed."
    Without digging too deeply, it can be found [islandnet.com] that Motorola came out with the 68020, a true 32-bit processor, in June of 1984, 11 years prior to the debut of the 32-bit processor according to the nimrod author. I don't have solid dates but I know that within a year of this timeframe Suns and Apollo workstations were using this chip.

    How disgraceful.

    blakespot

    • Other Wired article errors (Score:5, Informative)

      by clem.dickey ( 102292 ) on Monday July 22, 2002 @08:26PM (#3934172)
      The Wired article has other errors as well. A 32-bit CPU isn't limited to 4GB; that confuses address space with physical memory. The definition of exabyte is wrong (1000 petabytes, not 1000 terabytes). The 8080 in 1981? Closer to 1975. And many have mentioned the bogus "no compatibility" claim.

      One wonders if the whole thing wasn't a troll.
      • A 32-bit CPU isn't limited to 4GB;
        >>>>>>>>
        I will shoot myself if we ever go back to bank switching. I'm not kidding. Maybe I'll go postal first and knock off the guys at Microsoft who wrote the memory windowing extensions. Then I'll kill myself...
  • Let's say you have an elaborately-customized server setup. Let's even imagine that some of your storage for both data and programs isn't sitting at a single PC, but is in network-attached storage. Now, you want to upgrade the hardware to 64-bit without having to recompile everything - or maybe just upgrade some of the servers while continue to share program code off the storage.

    You get only one answer: AMD. You can take your complexly-configured servers and not have to redo them from scratch. And the hobbiest gains the same advantage - swap drives, compile yourself a 64-bit kernel, and forget about doing a virgin install of Debian 64.
    ___
  • Sure, everyone 15 years ago thought 4 GB of memory would be PLENTY. But how about in another 15 years? Will an exabyte of memory still be able to run the highest end applications including Microsoft Office 2017?
  • Just not the way you might think. An Intel Itanium-based computer running Linux64, Win64 (the codename for the 64-bit version of Windows 2000) or Windows XP 64-bit can run x86 (386, Pentium, Pentium Pro, etc) binaries unmodified. It will be significantly SLOWER than an equivalent x86 processor, because it does do it via hardware emulation, but it does do it.

    Where the Itanium (and, I'm assuming, the Opteron/64-bit Athlon) really matter is in in large database and high-end workstation solutions. Basically, anything that needs more than 4GB of RAM. In these uses, it's not actually the processor speed that is needed, it's the RAM. The Itanium is meant for servers, yes. That is all the Itanium was designed for.

    The cleverly named Itanium-2, however, is a horse of a different color. Not only is it faster (both MHz and IPC,) but it's cheaper, too! (You can get an Itanium-2 based system for about $3000.) The Itanium 2 at 900MHz is about twice as fast as the 'old' Itanium at 800MHz, performance-wise.

    The only thing AMD has going for them (literally) is x86 compatibility. If it can run x86 code reasonably fast (i.e., a 1GHz Opteron running Pentium code at least as fast as a Pentium 3 1GHz) then it will be likely to take over the Workstation market from the Itanium 2. Unfortunately, I don't think anything could cause the Opteron to win over Itanium 2 in the high end server market.
  • ... so 4 GB was both unaffordable and generally not needed. But the recent advent of Windows XP and digital media has changed all of that.

    Gimme a break! The reason has nothing to do with Windows XP. It has to do with databases more than anything. Crikey.

  • HP Endorses AMD Chip? (Score:3, Funny)

    by Gerdts ( 125105 ) on Monday July 22, 2002 @08:35PM (#3934222)
    "You wouldn't buy a DVD player that wouldn't play your CDs, would you?" said Jerry Huck, chief architect at Hewlett-Packard.

    I am sure that Intel is really happy that the chief architect for their partner in their 64-bit efforts is endorsing the competing technology.

  • I think it's great that there's another Itanium compeditor (although the target markets are different). However, I'd much rather see x86 compatability through software. Last I heard, the Itanium runs x86 code about as fast as a 600 MHz PII. This shouldn't be that hard to beat in software on a 2 GHz chip, particularly if they use a JIT compiler.

    Are there any ports of bochs that pass system calls through to the native system so that none of the actual OS is running inside Bochs? This would allow you to, say, run x86 Linux code on Linux PPC or Win x86 apps on Win ia64. This assumes, of course, that the system call numbers and arguments are the same across architectures. Maybe it would require too much OS-awareness in Bochs in order to fix the endianess, but it would be nice to move away from hardware x86 decoders.

    Please someone tell me that all of the 64-bit mode instructions are the same length. (Maybe the caryover instructions from x86 need to be padded with nops.) Varaible-width instructions absoutely kill hardware or software decoding speed, especially if you're trying to parallelize it. Maybe we can all migrate to pure x86-64 instructions and slowly rid ourselves of the old x86 instructions?

    Ideally, AMD would come out with a RISC cpu with an open source x86 emulator for the OS vendors to integrate with thier OS. I would love to be able to have comodity RISC or VLIW chips on pricewatch. x86 decoding is a waste of heat and chip realestate.

  • The Opteron is compatible with all software made since the 8086. Therefore, the Opteron cannot truly be called new technology. It may have evolved in certain ways, but at its core it is no more advanced than the 8086. You can read AMD's whitepaper, and it will confirm: AMD knows that RISC, or specifically VLIW, is faster than CISC, but doesn't want to switch because of the installed base.

    Intel, with the Itanium, takes the opposite stance. They know that CISC sucks, and that x86 was doomed from the start. It's not that "new things are better"; VLIW processors could have been developed in 1980, and if they were there would be no need for Itanium. But they didn't. So Intel wants to use 64-bit as an excuse to throw out x86, and start over the way they should have from the beginning.

    Let's hope that Intel uses it's 75% marketshare power to win. It'll be unfortunate if AMD does.

    • Re:They got it (Score:3, Insightful)

      by SQL Error ( 16383 )
      So much cluelessness, so little time...

      The Opteron is radically different to processors from the 8086 up to the original Pentium. It's a super-scalar 64-bit RISC core with hardware translation of x86 (and x86-64) instructions. It's designed as a low-cost 64-bit upgrade to the Athlon; the Opteron core is only about 10% bigger than the Athlon core, and will sell in the same price range.

      Recent designs like the Athlon and P4 have thoroughly discredited the performance claims of RISC vs. CISC; the x86 translator has little or no impact on the overall performance. It all comes down to details of implementation. (The 8087 FP model is one exception, and SSE2 has now fixed that.)

      Itanium is a huge and expensive server chip, designed to compete with other huge and expensive server chips. The original Itanium was also something of a slug, providing fair-to-middling floating point performance and lousy integer performance. The Itanium 2 is supposed to have fixed this, bringing integer performance up to decent levels (though still slower than recent Athlons and P4s) and floating point to match IBM's Power 4. The results are still estimates though, so we'll have to see what actually gets listed on spec.org.

      Of course, a dual Athlon or P4 box will be faster and cheaper (if your problem can be multi-threaded).

      The Athlon has good FP performance compared to previous x86 chips, but is still limited by the broken 8087 model. Opteron aims to fix this with an extended SSE2 mode.

      As for VLIW... This was primarily a *political* decision by Intel. Having spent so much time bagging RISC, they couldn't face bringing out their own RISC chip. So they spent many years and many billions of dollars on the Itanium - which sucked. It ran into the same compiler issues that VLIW has always had. If the performance estimates for Itanium 2 pan out, it would seem that Intel have managed to overcome these problems, or at least provide enough hardware to bulldoze their way through.

      And Itanium is NOT by any means a clean architecture. In fact, it's considerably more convoluted than x86. If you want a clean design, look at Alpha or MIPS.

      Bottom line: Opteron gives you 64-bit addressing and improved performance, with no penalty for running all your 32-bit applications. And it'll be cheap enough for all but the lowest end of the desktop market.

      Itanium 2 gives a big expensive chip for your big expensive servers, and provides decent performance as long as all your applications are recompiled.
  • We don not want an 80x86 compatible chip. It's crap. It's an outdated CISC architecture. Has anybody read the complete white paper on the IA64 chip? Intel may have completely screwed up the implementation, but as specified (by H.P. originally) the chip is kicking ass and taking names.

    Some extremely large percent of the silicon (and thus power dissipation and heat generation) on the athlon line is spent on the insanely complex variable length instruction decode needed to break old legacy x86 instructions into smaller pieces to feed to the well designed and powerful execution units.

    A well designed RISC with optimization and caching hinds built into the object code will kick the living shit out of a 64 bit CISC hack built on top of an instruction set that was designed to run pocket calculators and automatic washing machines.

Slashdot Top Deals

"Everything should be made as simple as possible, but not simpler." -- Albert Einstein

Close