El Transmeta Crusoe

Jose Galaviz Casas*

1.

Antecedentes

A principios de los 1980s, Joseph Fisher (HP) comenzo a hablar de

computadoras cuyas instrucciones estaban contenidas en palabras de memoria muy grandes, de cientos de bits [1]. La intencion de hacer esto es poder
poner en una sola instrucci
on larga, peque
nas instrucciones mas sencillas y
peque
nas que puedan ser ejecutadas por diferentes unidades funcionales del
CPU. De esta forma es posible paralelizarlas y aumentar el desempe
no. A
este tipo de arquitecturas se les denomina VLIW (Very Large Instruction
Word ).
A mediados de los 1990s, David Ditzel, a cargo de una jefatura tecnica
en Sun Microsystems en esa epoca, estaba experimentando con la emulacion
de c
odigo de arquitectura 80X86 en maquinas Sparc [3]. El objetivo era determinar que instrucciones haba que a
nadir a la arquitectura de Sparc para
hacer posible la ejecuci
on eficiente de instrucciones de 80X86. Por desgracia no era posible hacer tal cosa con pocas a
nadiduras a la arquitectura de
Sparc.
A David Ditzel le preocupaba la creciente complejidad de los procesadores, aun de aquellos que son inherentemente sencillos, los RISC. En general
los procesadores tienden a ser cada vez mas complejos, mas grandes y a
calentarse m
as y comenz
o a meditar acerca de la posibilidad de elaborar
procesadores con un dise
no simple y un alto desempe
no.
En 1995 Ditzel deja Sun Microsystems. Posea muchos contactos. Es
un miembro reconocido de la comunidad ingenierl, ha trabajado en Bell
Labs, Sun, y ha tenido cargos en IEEE y ACM. Todo esto le hizo posible
comenzar a reclutar ingenieros de hardware y software de muchos sitios para
llevar a cabo su proyecto. Entre los reclutados estan el ex-coordinador de
los proyectos de Motorola de la serie 680X0 y el reconocido hacker Linus
Torvalds (autor de Linux).
*

Departamento de Matem
aticas, Facultad de Ciencias, UNAM. jose@matem.unam.mx

54

Dadas las experiencias de Ditzel en emulacion, la intencion era dise

nar un
procesador capaz de emular otros, en particular a los Intel 80X86 (a los que
genericamente denominaremos X86). Pero la emulacion siempre impone una
carga extra, se invierte tiempo traduciendo instrucciones de una arquitectura
a otra, esto hace todo mucho mas lento. Como hacer emulacion y lograr un
procesador competitivo? el procesador tendra que ser sumamente eficiente.
Aqu es donde entra VLIW.
Una caracterstica relevante y deseable en todo procesador es que sea capaz de efectuar el mayor n
umero de operaciones posibles al mismo tiempo.
Si cada instrucci
on se divide en subtareas y varias subtareas de la misma
instrucci
on pueden ser hechas al mismo tiempo se dice que se tiene paralelismo a nivel de instrucci
on o ILP (Instruction Level Parallelism). VLIW
est
a pensado para hacer esto.
Para lograr ILP en una arquitectura RISC o CISC hay que hacer muchas
cosas en hardware. La responsabilidad de lograr ILP recae esencialmente en
el hardware. En cambio en una arquitectura VLIW es el software, concretamente el compilador, el encargado de tomar las decisiones necesarias para
obtener ILP.
En 1995 Ditzel funda Transmeta con el objeto de hacer realidad un
nuevo dise
no de procesador, eficiente, VLIW, sencillo y capaz de emular
otros procesadores mediante un programa que hace las veces de traductor
entre los lenguajes de la m
aquina emulada y el procesador real. En agosto
de 1999 los primeros chips de este nuevo procesador fueron producidos, los
primeros procesadores de Transmeta, conocidos genericamente como Crusoe.

2.

Problemas de emulaci
on

Hay muchos problemas cuando una maquina emula a otra. En general

estos problemas, al menos los mas graves, se deben a que cada maquina
representa de diferente manera sus estados.
Cada procesador es una maquina de estados. Con base en el estado del
procesador en un instante determinado se toman decisiones que determinan
el flujo del programa posteriormente. Entonces cuando una maquina B emula
a otra A, B debe mapear los estados de A a los propios de manera adecuada,
para asegurarse de tomar las mismas decisiones de flujo de programa que
tomara A en las mismas circunstancias.
Si no hay una correspondencia entre los estados de la maquina emulada
y la emuladora pueden ocurrir, en esta u
ltima, cosas que nunca hubieran
ocurrido en la primera. Por ejemplo, supongase que en un X86 la i-esi-

55

Figura 2.1: La segunda instruccion del codigo de X86 genera una excepci
on de divisi
on por cero. Al fragmentar y reacomodar las operaciones mas
elementales, en que cada instruccion de X86 es dividida por una maquina
VLIW, puede ocurrir que sean ejecutados fragmentos de instruccion que
nunca sera ejecutados en el X86.
ma instrucci
on de un programa genera una excepcion de division por cero,
sup
ongase tambien que el X86 es emulado por una maquina VLIW capaz de
fragmentar cada instrucci
on de X86 en cuatro subtareas elementales paralelizables, a las que llamaremos atomos, y que es capaz de ejecutar hasta 8
atomos simult
aneamente, es decir su palabra de instruccion tiene 8 campos,
uno para cada subtarea. Imaginemos ahora que los atomos son reordenadas
como se muestra en la figura 2.1. En este caso ocurre que algunos atomos
que nunca debieron ocurrir, por estar despues de la instruccion que genera
la excepci
on, si son ejecutados en la maquina emuladora y, en principio,
pueden cambiar su estado, un estado que en el X86 emulado nunca hubiera
sido alcanzado.
Luego de analizar este problema, los ingenieros de Transmeta determinaron que la clave era mantener, en la maquina emuladora, un conjunto de
registros que conservaran el estado de la maquina emulada.
La fragmentaci
on en
atomos y el reordenamiento de estos no son tareas
exclusivas de las arquitecturas VLIW, se hace tambien para lograr ILP en
otras arquitecturas y para resolver el problema mencionado suele utilizarse
hardware complicado que, en esencia, regresa la maquina de estados del
procesador hasta un estado consistente, en cuanto se da cuenta de que ha
ocurrido una excepci
on y que se han ejecutado partes de instrucciones que
no ocurrir
an.
La soluci
on de Transmeta es diferente [2]. Todos los registros que mantienen el estado de la m
aquina emulada son duplicados, por cada uno de
ellos en realidad hay dos, una copia de trabajo y otra oculta (shadow en
terminologa Transmeta). Los atomos, en su ejecucion alteran solo la copia
de trabajo, hasta haber ejecutado todos los atomos correspondientes a un
bloque de instrucciones de X86. Entonces la copia de trabajo se respalda en
la oculta. A esta operaci
on se le llama commit. Si en alg
un momento durante
la ejecuci
on se detecta una excepcion entonces se regresa rapidamente a el
u
ltimo estado consistente copiando el respaldo oculto a la copia de trabajo,
a esto se le llama rollback. Luego se procede a ejecutar el mismo bloque de
atomos, pero esta vez en el orden en el que los ejecutara un X86, as cuando ocurra la excepci
on, ocurrira del mismo modo, al mismo tiempo y en el
56

mismo estado en que ocurrira en un X86.

Otro de los problemas que hay que resolver es de los alias. Imaginemos que una secuencia de instrucciones de X86 puede ser traducida en otra
m
aquina como:
1
2
3
4
5
6

load R30,[x]
...
store data,[y]
...
load R31,[x]
(instrucciones que usan R31)

Si no se altera el registro R30 en las lneas de codigo entre la 1 y la 5

entonces el segundo load sale sobrando y en las instrucciones que siguen a
la lnea 5 es posible usar R30 en vez de R31. Es posible optimizar el codigo
haciendo lo siguiente:
1
2
3
4
5

load R30,[x]
...
store data,[y]
...
(instrucciones que usan R30)

Esto nos ahorra un acceso a memoria, que por supuesto, es muy lento para
la velocidad usual del procesador. Pero solo es posible hacer esto si el store
de la lnea 3, que estamos suponiendo que es el u
nico store que ocurre, no
altera el contenido de la localidad x. Es decir si x y y direccionan la misma
localidad de memoria entonces eliminar el segundo load es un error, porque
no se accede al mismo valor.
Para resolver este problema, Transmeta implemento dos operaciones que
acceden a memoria y verifican que no haya alias, dos maneras diferentes de
referirse a la misma localidad: ldp (load and protect) y stam (store and
trap). En nuestro ejemplo el uso de estas instrucciones se vera as:
ldp R30,[x]
...
stam data,[y]
(instrucciones que usan R30)
La primera lnea carga en el registro 30 el contenido de la localidad x y
marca esa localidad como protegida, recuerda x. El stam verifica si y y x
son la misma direcci
on, en cuyo caso la optimizacion resulta en un error, entonces interrumpe la actual ejecucion, recupera el u
ltimo estado consistente
y ejecuta conservadoramente el codigo de X86.
57

Figura 3.2: Molecula de Crusoe. Cada molecula esta constituida por cuatro
o memos
atomos (instrucciones al estilo RISC) ejecutables en paralelo en
unidades funcionales diferentes.

3.

Code Morphing, traducci

on

El procesador Crusoe es entonces de arquitectura VLIW y es capaz de

ejecutar c
odigo binario de alguna otra arquitectura, en particular de X86.
Para hacer esto debe haber un paso intermedio que traduzca las instrucciones
de X86 a las nativas de Crusoe. El encargado de hacer esto es un software
llamado Code Morphing.
Code Morphing vive en un chip de ROM que se autocarga en memoria
al momento de prender la maquina, siempre esta all, traduce todo, absolutamente todo lo que se le diga el procesador. Ni el sistema operativo, ni
los programas de aplicaci
on, ni siquiera el BIOS se enteran de que no estan
corriendo sobre un X86 real, para ellos es transparente, como si estuvieran
en una m
aquina con la etiqueta Intel Inside.
El trabajo de Code Morphing es traducir las instrucciones de Intel X86
formando moleculas (en terminologa de Transmeta) de 128 bits de longitud
(de all que Crusoe sea VLIW, ver figura 3.2). Cada molecula esta constituida
de hasta 4
atomos, esas instrucciones elementales ejecutables en paralelo.
Los
atomos son instrucciones al estilo RISC de una maquina load-store. En
una sola molecula puede hacer una instruccion de punto flotante, una de
aritmetica entera, un acceso a memoria (load o store), y una instruccion
de salto, si en alg
un momento no hace falta uno de estos tipos entonces es
posible reemplazarlo por otra instruccion de aritmetica entera. Cada atomo
va dirigido a una unidad funcional independiente dentro del procesador,
as que se ejecutan al mismo tiempo.
El Crusoe tiene las siguientes unidades funcionales:
Dos unidades de aritmetica entera (ALU).
Una unidad de punto flotante (FPU).
Una unidad de load-store (load-store unit).
Una unidad de salto (branch unit).
Code Morphing traduce bloques de instrucciones de X86 y procura hacer
la traducci
on una sola vez (no es un interprete). Cada vez que se traduce
un bloque es guardado en un cache de instrucciones traducidas llamado
58

Translation Look-aside Buffer o TLB de 256 entradas. Considerando que

generalmente, en promedio, un 10 % del codigo de un programa es la parte
crtica que se ejecuta un 90 % del tiempo total del programa, el cache de
traducci
on hace que se amortice el costo de traduccion (en tiempo y energa)
sobre todas las ejecuciones del mismo codigo traducido.
Adem
as Code Morphing a
nade un peque
na cantidad de codigo extra a la
traducci
on. Estos a
nadidos, no funcionales para el programa en ejecucion,
tienen por objeto recabar datos estadsticos de la ejecucion, por ejemplo:
historia de los saltos (cuantas veces han sido tomados), frecuencia de ejecuci
on de ciertos bloques. Todo con el fin de poder predecir el comportamiento
futuro del programa y tomar decisiones ventajosas. Si casi siempre que se
pasa por la instrucci
on de salto X se decide saltar, entonces la proxima vez
que se pase por X se cargan de antemano las instrucciones que estan en
la direcci
on de salto, porque son las que muy probablemente sigan, si se ha
utilizado mucho un bloque de codigo se conserva en el cache de traducciones.
El nivel de detalle de los atomos permite ademas llevar a cabo optimizaciones como la siguiente. Supongase que se traduce el siguiente codigo de
X86
1
2
3
4

ADD
ADD
MOV
SUB

EAX,
EBX,
ASI,
ECX,

(ESP)
(ESP)
(EBP)
5

en una primera aproximacion la traduccion sera como la siguiente (se ha

decidido, por claridad llamar a los registros de Crusoe como aquellos de X86
que representan)
1
2
3
4
5
6

ld
add
ld
add
ld
sub

r30,
eax,
r31,
ebx,
esi,
ecx,

[esp]
eax, r30
[esp]
ebx, r31
[ebp]
ecx, 5

Esta es una traducci

on literal de las instrucciones de X86. Pero se observa
que las cargas de las lneas 1 y 3 son redundantes. Una mejor traduccion
sera:
1
2
3

ld r30, [esp]
add eax, eax, r30
add ebx, ebx, r30
59

4
5

ld esi, [ebp]
sub ecx, ecx, 5

lo que es f
acil de reordenar y acomodar en dos moleculas:
ld r30, [esp]; sub ecx, ecx, 5
ld esi, [ebp]; add eax, eax, r30; add ebx, ebx, r30

4.

Aspectos t
ecnicos

El Crusoe posee 64 registros de proposito general de 32 bits, como ya se

dijo, tiene un cache de bloques traducidos (TLB) de 256 entradas.
Posee tambien dos niveles de cache:
64 Kb de cache L1 de instrucciones y 64 Kb de cache L1 de datos,
ambos caches son asociativas de conjunto de 8 vas (8-way set associative).
Un cache de 256 Kb. de datos asociativo de conjunto de 4 vas write
back.
Las frecuencias de operacion llegan hasta los 700 MHz, utiliza tecnologa
CMOS (el chip es manufacturado por IBM) y tiene un area de 73 mm2 .
Por ser un procesador sencillo tiene menor tama
no que la competencia,
un Pentium III de Intel mide 106 mm2 . Esto tambien hace que, dado que
la densidad del chip es mucho menor, se caliente mucho menos que otros
(48o C contra 105o C del PIII). Esto influye de dos maneras diferentes en
el ahorro de energa: se desperdicia menos energa en forma de calor y se
usa menos energa en el subsistema de enfriamiento. Esto lo hace ideal para
c
omputo m
ovil (computadoras portatiles), mercado al que se ha orientado
Crusoe.
Para reforzar esta cualidad, Crusoe posee ademas la tecnologa Long
Run, que permite ahorrar energa disminuyendo o aumentando la frecuencia
del reloj en funci
on de la demanda del procesador. Seg
un Transmeta el
Crusoe hace que la batera rinda de 3 a 30 veces mas dependiendo de las
aplicaciones que se corran.

5.

Los puntos malos

No sin raz
on, los ingenieros de Transmeta hacen notar que los benchmarks usuales est
an orientados a equipos desktop, cuyos requerimientos de
60

gasto de energa no son estrictos y no impactan en la utilidad del sistema.

Esto lo utilizan como justificacion para poner sus propios benchmarks donde
resaltan el ahorro de energa [6].
No hay reportes de desempe
no de Crusoe que usen los benchmarks
est
andar reconocidos internacionalmente: no hay reportes del desempe
no
SPEC de Crusoe.
Si bien es cierto que los benchmarks usuales no hacen consideraciones
especiales importantes en equipos moviles, tambien es cierto que son los puntos de referencia que le permiten al mundo saber y comparar el desempe
no
de los equipos.
A
un con sus propios benchmarks los procesadores Crusoe no salen tan
bien librados, si ganan en las comparaciones es por poco. Por supuesto el
rubro sonde siempre ganan y por mucho, es en el de rendimiento de energa
[4, 5].
En benchmarks hechos por otras organizaciones dedicadas a las comparaciones de equipos, los procesadores Crusoe no resultan bien plantados, a
un
en el rubro de duraci
on de batera de equipos notebook. En algunos reportes
el Intel Celeron a 30 MHz menos que Crusoe, tiene una duracion de batera
de unas 3 horas m
as. En las pruebas de desempe
no populares, basada en la
ejecuci
on de juegos o de programas comunes, que no son tan robustas como
las pruebas de SPEC, pero que dan una idea, Crusoe tiene un desempe
no
muy por debajo de sus competidores naturales (Mobile Pentium III). En
uno de estos sitios incluso, pensando que era injusta la prueba, decidieron
compararlo con un Pentiun II y aun as el desempe
no de Crusoe fue inferior.
Uno podra pensar entonces en que la conveniencia es en la relacion
costo-beneficio, pensaramos entonces que Crousoe es muy barato. No es
as, un Crusoe cuesta actualmente unos 87 USD y un Celeron unos 69 USD.
Probablemente si la manufactura del chip no estuviera a cargo de una compa
na externa (IBM) los costos permitiran bajar el precio, pero Transmeta
no tiene capital suficiente para establecer sus propias plantas.
Quiz
as sea por todo eso que hasta hora solo muy pocas compa
nas han
incluido Crusoe en sus portatiles (Fujistu y Sony en algunos modelos Vaio,
por ejemplo). Como quiera que sea Transmeta no tiene finanzas muy estables, ha operado con n
umeros rojos durante el u
ltimo trimestre de 2000 y
las fluctuaciones del valor de sus acciones son grandes1 .
Algunos analistas han se
nalado otra desventaja de Crusoe: Code Morphing se carga en RAM para optimizar su ejecucion, pero al cargarse en
memoria crece su tama
no unas seis veces, el codigo mismo, sus estructuras
1

Fuente: http://www.nasdaq.com con el identificador TMTA

61

de datos y dem
as ocupan todo ese espacio que puede llegar a ser muy significativo. Code Morphing es indispensable en todo momento para que la
m
aquina funcione, es esencial para el procesador mismo, as que es como si
toda esa RAM que ocupa no existiera. Si juntaramos el costo de RAM y
el del procesador obtendramos una cantidad mayor que la necesaria para
comprar un procesador menos exigente y mas rapido.
Esperemos que se salve, tiene muchas buenas ideas, ideas que prometen
algo mejor de lo que ahora vemos.

Referencias
[1] Ramakrishna, Rau y Joseph A. Fisher, Instruction-Level Parallel Processing: History, Overview, and Perspective, The Journal of Supercomputing, 7, 1993, pp. 7-9. Tambien aparece en la referencia [7], pp.
288-308.
[2] Klaiber, Alexander, The Technology Behind Crusoe Processors, Transmeta Corporation, enero 2000.
[3] Geppert Linda y Tekla S. Perry, Transmetas Magic Show, Spectrum,
IEEE, 37(5), mayo 2000.
[4] Crusoe Processor, Model TM5400, Transmeta
http://www.transmeta.com, enero 18 de 2000.

Corporation,

[5] Crusoe Processor Benchmarl Report, Mobile Platform Benchmark Results, Transmeta Corporation, http://www.transmeta.com, febrero 3
de 2000.
[6] McKenna, Daniel, Mobile Platform Benchmarks, A Methodology
for Evaluating Mobile Computing Devices, Transmeta Corporation,
http://www.transmeta.com, febrero 3 de 2000.
[7] Hill, Mark D., N. P. Jouppi y G. S. Sohi (editores), Readings in Coumputer Architecture, Morgan Kaufmann, 2000.

62