The Crusoe Processor

  Crusoe Processor.pdf (Size: 222.88 KB / Downloads: 0)
ABSTRACT
The Transmeta Company introduced their Crusoe
processor in the January 2000 [4]. This processor was
based on the x86 architecture with a software layer called
Code Morphing Software (CMS) comprised of an
interpreter, a run time system, and code optimizer running
on top of the processor [1]. From an architectural stand
point it uses less transistors minimizing power
consumption; this however does not penalize performance
due to the 128 bit VILW instruction set architecture
which allows up to four instructions to be issued per clock
cycle. How is this achieved? Crusoe is the first processor
whose instruction set is implemented in the software; the
benefit of that being - the software could “learn” the
behavior of a program as it runs, improving with time by
recognizing patterns previously encountered and making
smart decisions based on those patterns, thus making it
the first “smart” processor.
The key to the Crusoe processor is in the CMS which
explores a unique approach called commit and roll back
supported by the hardware along with translation and
efficient interpretation of instructions. As a result of
CMS, Crusoe offers out-of-the box compatibility to most
operating system as well as an attractive choice for
mobile computing.
KEY WORDS
CMS – (Code Morphing Software) OS independent
software that acts as an interpreter on top of the
processor optimizing instructions and making
calculated decisions to enhance the processor’s
performance
Molecule – a VLIW instruction comprised of either two
or four RISC-like instructions
Atom – one RISC-like instruction. Multiple atoms form a
molecule.
Shadow - in the architecture there are two copies of each
register; a working copy and a shadow copy. It
can be compared to the mirroring approach of
RAID 1.
Rollback – when a fault is encountered the state of the
working register is rolled back to the state held
in the shadow register.
1. INTRODUCTION
The design of the Transmeta Crusoe processor tries to
address several problems that most engineers face when
designing a processor. The three main issues are:
1. Energy Efficiency
2. Compatibility
3. Performance
Energy efficiency is very important in mobile devices
where the focus is directed towards battery life versus
performance. As a result, design is bound by a series of
variables that depend on each other forcing designers to
choose between performance, battery life and light
weight. Often performance is scarified to gain more
energy efficiency. To resolve this problem, the Crusoe
processor uses less transistors than its rivals, thus using
less energy minimizing the amount of heat produced
allowing it to run cooler. At the same time, the
improvements just mentioned also translate into lighter
weight and make the processor less expensive to
manufacture eliminating the need of heat sinks and costly
fans.
Alone, a VLIW chip is incapable of running programs
designed for an x86 processor. As a result, the Crusoe
chips are paired with Transmeta's patented code-morphing
software (CMS), which converts x86 programs into
VLIW instructions that the chip can understand. In this
manner compatibility is achieved since CMS acts as an
intermediary between the x86 chip and OS or application
level. CMS software is platform independent interpreting
all instructions solving any ambiguity that could arise
between hardware and OS.
The other major issue pertains to performance, and this is
the department where CMS really shows what it can do.
The general idea is providing performance for a wide
variety of systems and applications ranging from floating
point calculations to graphics, media and desktop
computing. To accomplish this, CMS makes no
assumptions about the OS running on the processor and
does not have access to the executable files of the
application running [1], but interprets and translates the
code on the fly as the software executes.
2. THE CRUSOE TECHNOLOGY
Hardware
The technology implemented by the Crusoe processor is
something totally different from the rest of the industry.
At the hardware level, the architecture uses an elegant
approach by implementing a technique called register
shadowing. This is accomplished through two copies of
registers (Figure 1); a working copy where the
instructions are kept as they are being executed and a
shadow copy with the state of the last saved executed
translation.
Figure 1: Register shadowing
The instructions, also known as atoms only update in the
working copy of the registers and as execution reaches the
end of a translation without error the working registers are
update their respective shadow registers using a special
commit operation saving the work done in the translation
process. The reason this technique is employed is simply
to have a copy of the last successful translation saved in
the mirroring registers in case a problem arises. Such
problem could be where the CMS makes the wrong
translation assumption (i.e. take a branch when it should
have not been taken). In that case, the shadow registers
hold the values of the last successful translation, thus
making it easy to roll-back. The idea of roll-back is
simply restoring the last successful state previous to the
incorrect assumption or exception that was handled.
The VLIW processor uses a six stage pipeline
implementing two fetch instructions policy. This is simply
based on the “educated” decision made by the CMS on
what will happen next. Moreover, there are other
hardware implementations specific to the chip, aside from
the shadow registers; however, going into detail about
them is beyond the scope of this paper.
Code Morphing Software (CMS)
CMS is structured in the same way that other dynamic
translation systems are. It comprises of two major parts;
the interpreter and the translator. The interpreter decodes
and executes x86 instructions sequentially, monitoring
memory access order and reproduction of faults while
collecting data on execution frequency, branch directions
and memory I/O operations; all of which is later used for
making decisions based on past occurrences.
When the number of executions for a section of x86 code
reaches a certain threshold, the address is passed to the
translator [3]. The translator calculates the addresses
producing the native code from the x86 codes storing it
along with any related information in a translation cache.
From then on, CMS executes the translation until
something invalidates or reaches the end of the
translation. Figure 2 shows an abstract flowchart of how
CMS works and the steps that it follows. If a branch
exists, once the branch target is identified, the branch
operation is modified to go directly there, this procedure
is called chaining [2]. Over time, frequently accessed
regions of code begin executing entirely in the translation
cache without any type of overhead.
Figure 2: CMS representation
The translator is the largest and most complicated piece of
the puzzle made up of modules that decode the x86
instructions, analyze them and generate the VILW code
by optimizing the instructions and scheduling their
execution (in most cases out-of-order). Without hardware
support it would be virtually impossible to have dynamic
scheduling. In the x86 ISA, when an instruction causes an
exception all instructions preceding it must finish
executing before the exception is handled. Such problem
cannot be solved without hardware support; however, this
is where commit and roll back notion discussed earlier
comes in play. The shadow registers are holding a state
prior to the exception allowing rollback so the translator
could potentially reorder faulting atoms. Same notion
applies to interrupts, where the state of the registers is
restored to the state of the shadow after the interrupt is
handled. As a result, either two or four x86 atoms are
packed into a VILW molecule (Figure 3) which is then
executed in the pipeline. During execution CMS
guaranties correct operation through careful scheduling,
eliminating hazards by inserting no-ops if necessary to
stall execution. However, load operations that cause a
miss in the cache have an additional latency which is
handled by the hardware.
In this phase, the translator speculates the best executing
pattern as well as making assumptions about branches.
All the speculations and assumptions are checked and
validated at runtime. If an assumption fails leading to
overhead, CMS copes with this by monitoring reoccurring
instances and generates more conservative translation if it
decides that the failure rate is excessive.
In addition to the interpreter and instructions translation,
CMS also includes routines to handle I/O devices, which
can be accessed through explicit I/O instructions (i.e. read
or write). However in the case of Memory Mapped I/O,
CMS cannot distinguish at translation time whether the
instruction is a memory access or I/O having to wait until
runtime. When handling I/O within a program, CMS
keeps the order of instructions in the same way they
appear in the initial code since I/O calls cannot be rolled
back. Moreover, as a system, CMS has routines to handle
interrupts, traps, garbage collection, as well as exception
handling.
Figure 3: Processing of instructions in the translator
After exploring CMS support on the x86 chip it becomes
evident that the Crusoe processors’ simplicity in design is
largely due to the fact that the complex tasks are moved to
be handled by the software, more specifically by CMS.
This allows the software to make decisions that optimizes
performance, while the hardware is left to execute the
optimized VILW instructions passed by the translator.
One advantage to this scheme is that CMS can be tailored
to the processor as well as any special purpose devices
without changing the design of the chip.
3. CONCLUSION
The Crusoe processor developed by Transmeta offers a
few models ranging from 500 MHz to about 1GHz of
processing power while being energy efficient. This type
of processing power combined with the light weight and
energy efficiency is an attractive combination for mobile
devices. As a result, several desktop computer
manufacturers such as Sony, Hp have been using the
Crusoe processor on their notebooks as well as wireless
devices.
The marketing problems that Crusoe processor encounters
in desktop computing is mainly because large PC
manufacturers are under contract with the well known
processor corporations such as Motorola, Pentium, etc. At
the same time, Crusoe has not proven itself as a fierce
competitor to the above mentioned manufacturers, thus
remaining unknown outside of the tech world. At the
same time the complexity of the CMS doesn’t justify it as
a good alternative for the traditional processors. However,
the processor has been used in many mobile devices
either as stand alone or embedded, which means that
there’s a market for this technology. I’m not aware of any
limitations that the Crusoe processor might have, but
taking in consideration the implementation detail, it
makes a good alternative for special purpose processors
and possibly even for real-time systems. Since the CMS
can be tailored to the chip, I see no reason why that can’t
stand true for a special purpose system. One thing is clear,
although the tech world is aware of its existence, it has
not opted to fully embrace it as of yet.