Did I get the grub?
I'm still a little confused on the VLIW is something new and unique to transmeta angle. Here's some new and old news on the subject, it all makes me scratch my head. First, from yesterday's NYT:
Chip Innovator Bets on Brainpower, Not Battery Powerhttp://www.nytimes.com/library/tech/00/01/biztech/articles/24meta.html
By 1995, RISC had been overtaken in design circles by an approach called VLIW, for Very Long Instruction Word. But the philosophy was the same: Simplify the hardware and do more complex things in software. VLIW, Ditzel knew, would be his starting point.
Of course, by 1995, mysterious Merced was known to be in the works, I think scheduled to arrive in a couple short years. Chuckle or guffah, as you see fit. The terminology was a bit out of favor, though. Here's 3 excerpts from different articles by the same author:
Due to ship in 2000, Merced is the first processor to implement Intel's IA-64 architecture and its Explicitly Parallel Instruction Computing (EPIC) technology. Merced itself has 128 registers, each 64 bits wide. There are also 64 1-bit predicate registers.
EPIC has been billed as a new approach that applies some concepts from very long-instruction-word computing but that is altogether different from VLIW. Essentially, EPIC is intended to enable Merced to handle a large number of instructions and feed them to multiple on-chip functional units for execution on every clock cycle. (http://www.eet.com/story/OEG19990210S0063, 2/11/99)
Perhaps the highest profile for the technology will come from Intel, whose upcoming Merced will bring VLIW to the center stage of general-purpose computing. According to the company, Merced is not a VLIW architecture. It is an EPIC ? explicitly parallel instruction computing ? design. However, it does incorporate VLIW concepts, Intel admits. (http://www.eet.com/story/OEG19990514S0014, 5/15/99)
Before we get into the guts of the software, let's take a philosophical spin through Merced's hardware. In essence, Merced is a very-long-instruction-word (VLIW) architecture, which contains numerous execution units that simultaneously process multiple streams of instructions.
It turns out that VLIW is an acronym whose name Intel dares not speak. This has largely to do with the market failures of the earliest VLIW computers -- machines from Multiflow and Cydrome, which came to fruition in the mid-1980s. (http://www.byte.com/column/wolfe/BYT19990817S0014, 5/12/99)
That's Alexander Wolfe in all three articles, I guess he thought he could be a little cheekier in Byte, or had an editor less afraid of the Intel marketrons.
The thing that I find curious and maybe a little hopeful and hypeful about Transmeta is the code morphing religion- that there's no need for anyone or anything but their code morphing software to know the actual VLIW architecture. It may do a decent job of emulating x86, but the machine should do better if the app and OS source code was compiled directly into VLIW machine code. From one of the Alexander Wolfe articles above, "Analysis: VLIW chips will depend on smarter software", eet.com
As architects begin to field devices ? DSPs, multimedia chips and, soon, general-purpose microprocessors such as Intel's Merced ? built around very-long-instruction-word (VLIW) architectures, one big question looms: How will these chips perform when battle-tested under real-world conditions?
That's no theoretical question, because it is software that will decompose applications programs into the streams of parallel instructions required to feed the numerous on-chip execution units in a VLIW device. But if that software is inefficient, the hardware will not beat out today's superscalar architectures, experts agree.
"VLIW has a different kind of complexity than RISC," said Ray Simar, a Texas Instruments Inc. Fellow, based here, and head of the company's DSP architectures. "With VLIW, you've got a wealth of riches because of all the on-chip functional units, but you have to make sure you're getting the best use out of all of them."
"Everyone's trying to get a better compiler to hook better into the hardware," said Wen-mei Hwu, chairman of the computer-engineering program at the University of Illinois at Urbana-Champaign. "Each company has its own course and constraints."
The constraint of funneling everything through x86 machine code is a rather severe one. Intel has supposedly had plenty of problems getting the compiler right, and a lot of information useful in optimization is lost when you go from programming language source to x86 machine code.
It's early on, and maybe Transmeta isn't telling the whole story just yet. Or maybe their code morphing is good enough. I'm a bit skeptical at this point, though.
Cheers, Dan. |
