The x86 Processor Vendor that Isn’t
In early 2000 a secretive Californian MPU design startup called Transmeta Corporation broke five years of silence and went public with its seemingly self-contradictory goal of competing in the market for x86 compatible general purpose microprocessors with a family of VLIW processors that didn’t natively implement the x86 instruction set . To accomplish this feat an x86 compatibility software layer was inserted between their Crusoe VLIW processor and a conventional stack of x86 BIOS, x86 operating systems, and x86 applications. This scheme is compared graphically to a conventional x86 system architecture in Figure 3.
Figure 3 – Conventional and Transmeta x86 System Architectures
Unlike all previous attempts at software based x86 ISA compatibility, in which foreign code execution took on at best a secondary role to native program execution, Transmeta’s strategy was unique in that it proposed to sell non-x86 processors for the sole purpose of executing x86 applications under x86 based operating systems using software based ISA compatibility. There is no “back door” for users to obtain higher system performance through execution of applications natively coded for Crusoe. In fact Transmeta has not disclosed comprehensive details about the ISA of its VLIW microprocessor family and considers its freedom to change its native ISA at will in future revisions and products as a major competitive advantage over conventional “hard-wired” x86 processors.
In a sense, Crusoe is a microprocessor, indeed an entire ISA, designed to only ever run a single program – Code Morphing Software (CMS). CMS is Transmeta’s name for its combination emulator/translator/optimizer firmware that comprises the x86 compatibility software layer for Crusoe and its second generation VLIW family, the Efficeon. When a Transmeta processor is powered up or reset it begins by loading CMS from EPROM into a special reserved region of memory, typically, 16 MB. This memory is reserved for the exclusive use of CMS and any x86 operating system and BIOS that runs on top of CMS isn’t even aware of its existence . That is, a Crusoe based system with 64 MB of memory appears to the x86 coded BIOS and operating system as a 48 MB x86 platform. Only about ½ MB of the reserved memory is required for the VLIW native code that comprise CMS, the remainder is used as a sort of cache to store the most recently translated native code segments generated by CMS’s execution of x86 software (including application, operating system, and BIOS). CMS operates in a similar manner to FX!32 – interpreting x86 code encountered for the first time, profiling the code and identifying sections for translation into native VLIW code. However, while the FX!32 translator operates off-line so to speak, and stores translated code segments to disk for later use, CMS operates like a combination of interpreter and just-in-time (JIT) compiler. Sections of x86 programs under execution are translated to equivalent VLIW code segments on the fly to speed up x86 program execution and the most recently used segments are retained in the 16 MB cache area reserved in main memory.
Some accounts of Transmeta’s unique approach have simplistically portrayed it as a kind of universal processor. The implication being that simply by changing CMS functionality that one could easily create a hardware/software system that would execute 68k code or SPARC code with equal facility as the x86 target chosen. In reality, an idealized platform neutral processor is not what Transmeta created. Crusoe, and even more so Efficeon, are VLIW processors expressly designed to host the x86 instruction set as efficiently as possible. This is accomplished by incorporating as many of the more arcane and performance-sapping aspects of the x86 ISA (“x86-isms”) in hardware as possible without unduly burdening the basic operation of the VLIW host processor.
Discuss (18 comments)