Professional Documents
Culture Documents
INTRODUCCIN
Desde hace ya algunos aos, la tendencia general en la fabricacin de CPUs se ha basado en conseguir sobre todo dos objetivos: Compatibilidad con la arquitectura llamada !"# $l mayor rendimiento posible en aplicaciones#
Para lograr ambos objetivos, los principales fabricantes %como &ntel o '(D) fabrican procesadores cada ve* m+s r+pidos y complejos, con una arquitectura interna de tipo ,&-C# Por tanto, para lograr ejecutar las instrucciones de la familia !", estas CPUs reali*an una traduccin del cdigo mediante un hard.are espec/fico# 0as CPUs modernas poseen otro hard.are especial para optimi*ar y reordenar cdigo en tiempo de ejecucin# 1odos estos elementos hard.are requieren espacio en la CPU y consumen energ/a el2ctrica# $l procesador Crusoe, en cambio, traslada estas funciones a una capa de soft.are, muy estrechamente ligada al hard.are de la CPU, resultando un procesador con menos superficie de silicio y menor consumo# $sto significa que los recursos habituales de una CPU como los encargados de la ejecucin de instrucciones, sumas, restas, multiplicaciones, etc# son compartidos por los procesos de usuario y los espec/ficos para las funciones de traduccin de cdigo, renombrado de registros, reordenamiento de instrucciones, etc# $ste soft.are de conversin de cdigo %Code (orphing) reside en una ,3( especial de la CPU, de tal manera que sea el primer soft.are en ser cargado por la CPU, situ+ndose desde ese momento como una capa intermedia entre las aplicaciones soft.are %incluido el sistema operativo) y el hard.are#
-e trata de una CPU de tipo 40&5 %4ery 0ong &nstruction 5ord), capa* de ejecutar hasta 6 operaciones por ciclo de reloj# ' continuacin pasaremos a describir los detalles t2cnicos de esta nueva familia de procesadores#
ESTRUCTURA INTERNA
Debido a la e clusin de elementos de hard.are complejos %y caros), debido a la reali*acin de ese trabajo por la capa de soft.are, los procesadores Crusoe poseen una estructura interna simple y muy eficiente, compuesta por: Dos unidades enteras %&nteger '0U)# Una unidad de coma flotante %7loating Point Unit)# Una unidad de memoria para operaciones de lectura y escritura %0oad 8 -tore Unit)# Una unidad de salto %9ranch Unit)#
0as instrucciones pueden ser de "6 o :;! bits, y el fabricante les llama <mol2culas=# Cada mol2cula puede contener hasta cuatro instrucciones de tipo ,&-C, llamadas <+tomos=# 1odo los +tomos de una mol2cula son ejecutados en paralelo, y la estructura de la mol2cula informa de cmo dichos +tomos deben ser conducidos hacia su correspondiente unidad de proceso, logrando as/ simplificar el hard.are de decodificacin y planificacin de las operaciones#
0as mol2culas se ejecutan en orden, evitando as/ complejo hard.are para operaciones fuera de secuencia# Para conseguir que el procesador ejecute instrucciones a la m+ ima velocidad, las mol2culas se intenta que est2n lo m+s llenas posible de +tomos#
Figura 1. Una molcula puede contener hasta cuatro tomos, que son ejecutados en paralelo.
$l banco de registros est+ formado por "6 registros enteros, >r? al >r"@# Parte de estos registros pueden estar usados por el soft.are de Code (orphing# $l ensamblador definido para este procesador, que observaremos m+s tarde, representa una mol2cula por l/nea, con +tomos separados por el s/mbolo punto y coma# 0os procesadores superescalares actuales, basados en la arquitectura !" de &ntel,
disponen de un hard.are dedicado a funciones tales como reordenar las instrucciones fuera de secuencia# Dicho hard.are consume mucha energ/a, adem+s de ocupar m+s espacio de silicio#
Una ventaja de tener como Anico programa en contacto con el hard.are de la m+quina el Code (orphing es que para modificar el comportamiento, o reali*ar optimi*aciones
basta con modificar el Code (orphing, sin afectar los cambios a las aplicaciones escritas para !"# $ste ocultamiento de la arquitectura bajo una capa de soft.are soluciona en gran medida un problema que poseen los procesadores 40&5 tradicionales, e incluso los !" tradicionales, ya que e ponen detalles sobre el pipeline del procesador a los compiladores# $sto requiere que los programas binarios antiguos deban ser recompilados, si no para permitir que sigan funcionando, al menos para poder aprovechar las mejoras que aporta el nuevo hard.are# $ste problema se aborda por los procesadores Crusoe, ya que el Code (orphing siempre <recompila= y optimi*a el cdigo !" que est+ ejecutando# &nevitablemente, esta optimi*acin din+mica de cdigo requiere ciclos de reloj, que podr/an ser usados por otros programas de usuario#
$n sus primeros productos, la empresa 1ransmeta ha tra*ado la l/nea divisoria entre hard.are y soft.are de tal forma que el soft.are se encarga de la compleja tarea de
decodificar las instrucciones !" y generar mol2culas paralelas, que el hard.are ejecuta a trav2s de un motor 40&5 muy simple, pero de gran velocidad# Unas pocas funciones hard.are, que e plicaremos m+s adelante, han sido aadidas para proporcionar un mejor soporte a la traduccin din+mica# $sta l/nea divisoria entre hard.are y soft.are puede ser modificada, de manera que favore*ca las e igencias de otro sector de productos, como por ejemplo servidores de gama alta# 0a figura @ muestra de manera gr+fica la divisin que utili*a el procesador Crusoe#
DECODIFICACIN Y PLANIFICACIN
0os procesadores !" superescalares e traen instrucciones !" binarias de la memoria y la decodifican en microCoperaciones, que son reordenadas por un hard.are espec/fico de planificacin e introducidas en las unidades funcionales para una ejecucin en paralelo#
$n cambio, el Code (orphing puede traducir un grupo de instrucciones !" a la ve*# (ientras que los !" tradicionales traducen una instruccin !" cada ve* que se ejecuta, el soft.are de 1ransmeta traduce las instrucciones una sola ve*, guardando el resultado
de la traduccin en una cache de !ad"cc#$%, de tal forma que la pr ima ve* que se ejecute esa instruccin se evitar+ el paso de la traduccin, ejecutando el cdigo optimi*ado que se encuentra en la cach2 de traduccin# &mplementar el paso de traduccin in soft.are abre nuevas oportunidades y retos# Debido a que un procesador fuera de secuencia %outCofCorder) debe traducir y planificar instrucciones cada ve* que se ejecutan, deben hacerlo de manera muy r+pida# $sto limita dr+sticamente los tipos de transformaciones que puede producir dicho hard.are# 0a apro imacin que reali*a el Code (orphing, en cambio, puede <amorti*ar= el coste de la traduccin en varias ejecuciones, permiti2ndole usar algoritmos de traduccin y planificacin mucho m+s sofisticados# 'dem+s, el coste energ2tico tambi2n se reduce, al no tener que reali*ar esas funciones hard.are cada ejecucin de una instruccin# 7inalmente, el soft.are de traduccin puede &' #(#)a! e* c$d#+& +e%e!ad& y potencialmente reducir el nAmero de instrucciones ejecutadas en una traduccin# Dicho de otra forma, Code (orphing puede acelerar la ejecucin al tiempo que reduce el consumo de energ/a y el calor disipado#
CACHE
0a cache de traduccin, junto con el cdigo del Code (orphing, reside en un espacio de memoria separado, inaccesible para el cdigo !"# Para un mejor rendimiento, el soft.are Code (orphing se copia a s/ mismo de ,3( a D,'( en la fase de inicio# $l tamao de este espacio de memoria puede ser especificado en el arranque, o el sistema operativo puede hacer dicho espacio ajustable#
Como todo sistema de cache, la t2cnica de reutili*acin de traducciones del Code (orphing toma ventaja de la pro!imidad de referencias# (+s concretamente, el sistema de traduccin e plota el alto grado de ratios de repeticion %el nAmero de veces que un
bloque traducido es ejecutado en media) observado en las aplicaciones reales# 1ras haberse traducido un bloque, las repetidas ejecuciones tienen 2 ito en la cach2 de traduccin y el hard.are puede ejecutar la traduccin optimi*ada a la m+ ima velocidad# 'lgunos programas de benchmarD tratan de reali*ar una gran cantidad de operaciones en poco tiempo, con muy poca repeticin, algo que difiere del uso normal de las aplicaciones# $l bajo rendimiento del Code (orphing en dichas pruebas se hace evidente# $n cambio, el Code (orphing <aprende= sobre los programas cada ve* que se ejecutan, y optimi*a su ejecucin para que cada ve* 2sta sea m+s r+pida#
FILTRADO
Eeneralmente, en las aplicaciones t/picas una pequea parte del cdigo %a menudo menos del :?>) ocupa m+s del FG> del tiempo de ejecucin# $s por ello que el sistema de traduccin debe escoger cuidadosamente cuanto esfuer*o dedicar a la traduccin de todo cdigo !" que le llegue# $l Code (orphing incluye gran variedad de modos de ejecucin para el cdigo !", que van desde la interpretacin %que no tiene penali*acin por traduccin, pero ejecuta cdigo !" m+s despacio), pasando por la traduccin usando generacin muy simple, hasta cdigo altamente optimi*ado %que requiere m+s tiempo de traduccin, pero ejecuta mucho m+s r+pido una ve* generado)# Un sofisticado conjunto de heur/sticas ayudan a elegir entre esos modos de ejecucin bas+ndose en la informacin que din+micamente aporta el cdigo durante su ejecucin#
Anico propsito es recoger informacin tal como frecuencias de ejecucin del bloque, o histrico de saltos# $sta informacin puede ser usada posteriormente para decidir cu+ndo y qu2 optimi*ar y traducir# Por ejemplo, si un salto en mayor medida la parte de cdigo a la cual se suele saltar# $n otro caso, para saltos m+s equilibrados %que pueden o no ser tomados, por ejemplo), el traductor puede ejecutar especulat/vamente ambas partes de cdigo y seleccionar el resultado correcto despu2s# 'n+logamente, sabiendo con qu2 frecuencia se ejecuta una parte del cdigo !" ayuda a decidir cu+nto se debe intentar optimi*ar ese cdigo# $ste tipo de decisiones ser/a e tremadamente dif/cil de abordar por las implementaciones !" tradicionales, basadas Anicamente en hard.are# !" tiene un comportamiento frecuente %por ejemplo, normalmente salta), el sistema puede optimi*ar
A. addl %eax, (%esp) // load data from stack, add to %eax B. addl %ebx, (%esp) // ditto, for %ebx C. movl %esi,(%ebp) D. subl %ecx,5 // load %esi from memory // subtract 5 from %ecx re ister
$n una primera pasada, el sistema de traduccin decodifica las instrucciones !" y las traduce a una secuencia simple de +tomos# $n este punto, todav/a es f+cil de ver la correspondencia entre el cdigo original y el generado# %0os registros >r@? y >r@: se usan como temporales para operaciones de lectura de memoria#)
ld %r!", #%esp$ add.c %eax,%eax,%r!" ld %r!&, #%esp$ add.c %ebx,%ebx,%r!& ld %esi, #%ebp$ sub.c %ecx,%ecx,5
//load from stack, i%to temporary //add to %eax, set co%ditio% codes
$n una segunda pasada, el optimi*ador aplica optimi*aciones bien conocidas por los compiladores# $sta fase pone de manifiesto optimi*aciones que una implementacin slo de hard.are no puede hacer: una traduccin basada en soft.are puede eliminar +tomos del flujo de instrucciones, en lugar de simplemente reordenarlas# $n este ejemplo, todas menos la Altima opcin de comando de establecimiento de condicin %#c) son innecesarias, y uno de los +tomos de carga %ld) es redundante, quedando menos +tomos para ejecutar#
ld %r!", #%esp$ add %eax,%eax,%r!" add %ebx,%ebx,%r!" ld %esi, #%ebp$ sub.c %ecx,%ecx,5
//load from stack o%ly o%ce //reuse data loaded earlier //o%ly t'is last co%ditio% code %eeded
$n un Altimo paso, el scheduler reordena los +tomos agrup+ndolos en mol2culas individuales# $ste proceso es similar al reali*ado por el hard.are llamado dispatcher de los procesadores de fuera de secuencia# $n cambio, usar soft.are para planificar el cdigo, resulta m+s fle ible a la hora de usar algoritmos de planificacin m+s efectivos#
&. ld %r!", #%esp$( sub.c %ecx,ecx,5 ). ld %esi, #%ebp$( add %eax,eax,%r!"( add %ebx,%ebx,%r!"
E-CEPCIONES Y ESPECULACIN
-in un hard.are espec/fico es generalmente dif/cil, para un sistema de traduccin din+mico, modeli*ar correctamente la sem+ntica de las e cepciones logrando a su ve*
un rendimiento adecuado# 0a ra*n es que la sem+ntica de las e cepciones impone severas restricciones sobre la planificacin de instrucciones# Consideremos el ejemplo anterior, en el que el siguiente cdigo !":
A. addl %eax, (%esp) // load data from stack, add to %eax B. addl %ebx, (%esp) // ditto, for %ebx C. movl %esi,(%ebp) D. subl %ecx,5 // load %esi from memory // subtract 5 from %ecx re ister
&. ld %r!", #%esp$( sub.c %ecx,ecx,5 ). ld %esi, #%ebp$( add %eax,eax,%r!"( add %ebx,%ebx,%r!"
$n la arquitectura &-' de los !", las e cepciones son precisas, cuando una instruccin genera una e cepcin, todas las instrucciones precedentes deben completarse antes de ser comunicada dicha e cepcin, y ninguna de las instrucciones posteriores deben completarse# -e puede observar que en la traduccin mostrada, los +tomos se suceden fuera de secuencia respecto al cdigo !" original# -upongamos ahora que durante la ejecucin la instruccin de carga %ld) de la mol2cula 2, correspondiente a la instruccin !" C, genera un fallo de p+gina# -in embargo, en ese instante, el procesador ha ejecutado ya cdigo en la mol2cula 1 correspondiente a la instruccin %, lo cual viola las reglas de las e cepciones precisas#
,esolver este problema sin un hard.are espec/fico restringe la planificacin de instrucciones de manera indebida, o requiere instrucciones adicionales, cada una reduciendo el rendimiento del sistema en el caso comAn en que no ocurran e cepciones#
0os procesadores con ejecucin fuera de secuencia tradicionales tambi2n padecen este problema# Hormalmente utili*an mecanismos complejos de hard.are para retrasar o deshacer los efectos de microoperaciones ejecutadas <demasiado pronto=# $l procesador Crusoe proporciona una solucin hard.are mucho m+s simple que trabaja codo con codo con el soft.are Code (orphing# ' todos los registros que contienen informacin sobre el estado !" se les reali*a una operacin de shadow, es decir, e isten dos copias de cada registro, la actualmente en ejecucin y la shadow# 0os +tomos normales slo actuali*an la copia actual de los registros# Cuando la ejecucin alcan*a el final de una traduccin sin encontrar una e cepcin, una operacin especial de actuali*ado %commit) copia todos los registros actuales a sus correspondientes registros shadow# Por otra parte, si cualquier e cepcin a nivel !" ocurre durante la traduccin, el sistema deshace los efectos de todas las mol2culas ejecutadas desde el principio de la traduccin# $sto se reali*a mediante una operacin llamada de roll&ac', que restaura los valores de los registros actuales con las copias % shadow) e istentes previamente a la traduccin# $n este punto, el Code (orphing reCejecuta las instrucciones !" cuidadosamente, es decir, en su orden original, con el fin de determinar la posicin concreta de la e cepcin# Deshacer cambios en la memoria es ligeramente m+s complejo# $l procesador Crusoe mantiene las operaciones de escritura %store) llenando los datos almacenados en un buffer %gated store &uffer), de donde slo son llevados a memoria en la operacin antes comentada de commit# $n una operacin de restauracin, las operaciones de store que no han recibido la operacin de commit, pueden ser simplemente borradas del buffer# Para aumentar la velocidad en el caso m+s comAn %sin e cepciones), el hard.are del procesador Crusoe est+ diseado para que las operaciones de actuali*ado %commit) sean pr+cticamente <gratuitas=#
ALIAS DE HARDWARE
Cuanta m+s libertad posea el planificador para mover +tomos en el llenado de mol2culas, mejor cdigo generar+ normalmente# Uno de los mayores l/mites a esta
libertad viene dada por las potenciales dependencias entre operaciones de memoria# $n particular, a menudo ser/a deseable reordenar operaciones de lectura delante de operaciones de escritura# $n cambio, hacer esto es incorrecto si la operacin de lectura usa datos de la operacin de escritura, y esta no es tarea f+cilmente reali*able en tiempo de traduccin# $l procesador Crusoe proporciona el innovador sistema de hard.are alias que ataja en cierta medida el problema# Cuando el traductor mueve una operacin de lectura delante de una de escritura, convierte la de lectura en una de lecturaCyCproteccin %que adem+s de leer los datos tambi2n registra las direcciones y tamao de los datos le/dos) y la de escritura en una de escrituraCbajoCmascaraCdeCalias %que verifica regiones protegidas)# -i la operacin de escritura sobreescribe los datos antes le/dos, el procesador lan*a una e cepcin y el sistema puede reali*ar la correccin# Usando este mecanismo, siempre es seguro el reordenamiento de instrucciones de lectura y escritura en memoria# De nuevo, el procesador Crusoe proporciona un mecanismo hard.are muy simple, que combinado con soft.are es capa* de resolver el problema#
CDIGO AUTO.MODIFICA/LE
' veces, las instrucciones !" en memoria se sobreescriben, bien porque el sistema operativo est+ cargando un nuevo programa, o porque una aplicacin est+ utili*ando cdigo autoCmodificable# Cuando ocurre esto al cdigo ya traducido, el Code (orphing debe ser avisado para evitar que ejecute cdigo antiguo errneamente# Con este fin, cuando el sistema traduce un bloque de cdigo !", protege contra escritura la p+gina de memoria !" que contiene ese cdigo# $sto lo hace utili*ando un bit dedicado en la entrada de esa p+gina, situada en la unidad de manejo de la memoria %((U)# Como sucede con otros detalles del hard.are 40&5, ese bit es invisible para el soft.are !"# Cuando una p+gina protegida es escrita, el remedio m+s simple es invalidar el o las traduccion%es) implicada%s)# Como el sistema aprende de manera din+mica acerca del comportamiento del programa, utili*a estrategias muy sofisticadas#
Completo soporte de -ystem (anagement (ode %--() $ncapsulado cer+mico compacto 9E' de 6I6 pines#
$n la figura 6 se puede observar a grandes rasgos el diagrama de bloques del procesador Crusoe 1(G6?? de 1ransmeta#