Slashdot Mirror
The Battle in 64-bit Land, 2003 and Beyond
An anonymous reader writes "Paul DeMone has an excellent article up at Real World Technologies on the future of 64bit computing. Find out where MIPS, HP, Intel, AMD, Sun, Fujitsu, and IBM are headed."
← Back to Stories (view on slashdot.org)
TOKYO, March 2, 1999 -- Sony Computer Entertainment Inc. is pleased to announce the co-development with Toshiba Corp. of the 128 bit CPU ("EE", or "Emotion Engine ") for use in the next generation of PlayStation . In order to process massive multi-media information at the fastest possible speeds, data bus, cache memory as well as all registers are 128 bits; this is integrated on a single chip LSI together with the state of the art 0.18 micron process technology. The development of a full 128-bit CPU is the first of its kind in the world.
Heat dissipation, in watts, is listed in the table near the end. I believe it was mentioned a couple times, especially in conjunction with the PPC 970 processor.
This article didn't address the embedded space. Who in their right mind is going to stick a CPU with a die size about that of a pack of playing cards in an embedded device?
Notice the absence of the XScale and Hitachi lines of embedded processors? This was a preview of the direction of 64-bit SERVER and WORKSTATION processors.
While you are right, power is a concern, it is way down on the list for the target audience of that article.
Learning HOW to think is more important than learning WHAT to think.
Most users won't need more than 32bits for years. By 2010 normal people will probably want 64bit desktops so they can have more than 4 gigs of ram (although Intel may be able to trick them with their 36bit extension).
128bits is a LOT.
Don't be fooled by the emotion engine in the PS2. It is 128bit in the sense it can handle 4 32bit floating point numbers at once. Guess what? So does Altivec, SSE, etc!
Calling systems 128bits is like calling the Atari Jaguar 64bit when it was powered by the good old 68000 that powered the 16bit Gensesis, 16bit Amiga, etc.
Typically the number of bits something is referrs to how much memory it can address (2^32bit=4gigs for example). Marketting likes to calling things 128bit (PS2 can handle multiple 32bit numbers at once), 64bit (Jaguar had a memory bus capable of moving 64bits at once), or 24bit (The Neo Geo had a 16bit 68000 and a 8bit z80) to get your attention.
PCs do not even today have lousy I/O. In fact, because the PC architecture has less registers, code needs to store stuff in memory more often, which lead to PCs outperforming RISC machines in memory bandwidth over the years. Sun and IBM in particular have been outperformed in RAM bandwidth for over a decade. They mad up for it in good floating point performance, but now the PCs are catching up there as well.
;-)
By the way, AMD's HyperTransport and Hammer memory infrastructure is quite similar to the "perfect scalability" Alpha memory hardware that has been making headlines recently. I expect Hammer to rule the planet here. Madison also has huge memory bandwidth, but it wastes most of it reading NOPs and instructions that are predicated away or otherwise discarded.
Also, if you actually read the article, you will notice that even the PowerPC translates their ugly and complex instruction set to an internal instruction set, which is more RISCy. This is the very thing that RISC afficionados have been using as argument against x86 for years!
The world isn't that black and white.
Have you even looked the IA64 ISA? It is a significant departure from x86. IA64 supports x86 instructions through emulation only (which is why x86 perf on IA64 is lagging.) It is not a 64-bit extension of IA32, which is an extension of IA16.
With IA64, there are 128 integer and floating point registers, 64 1-bit predication registers, eight branch registers, instructions are fixed length, every instruction can be predicated, speculative execution is supported at the instruction level, registers are preserved across function calls with register stacks, and register rotation can help prevent explicitly prevent antidependencies in tight instruction loops. Each of these is a departure from x86
I'm not too sure of this fact (and I am too lazy to double check) but I'm pretty sure IA64 requires a 64-bit operating system to even boot, unlike x86 which boots to 16-bit real-mode, and then is switched to 32-bit protected mode by the OS.