Você está na página 1de 9

IA-64 y el Intel Itanium

Jose Galaviz Casas*

1.

Antecedentes

Una de las primeras computadoras que uso pipeline (probablemente la


segunda) fue el modelo 6600 de Control Data Corporation (CDC). La CDC
6600 apareci
o en 1964 y fue la primera a la que se le denomino supercomputadora, fue dise
nada por Seymour Cray quien en 1972 dejo Control Data
para fundar su propia empresa, la que prolongara la estirpe de las supercomputadoras, Cray Research1 . Hoy en da los procesadores que utilizamos
cotidianamente poseen pipeline.
La primera m
aquina con memoria cache fue el modelo 85 del sistema
IBM 360 en 1968, un mainframe tpico. Hoy en da nuestras computadoras
personales tienen tpicamente uno o dos niveles de cache.
En las u
ltimas decadas hemos sido testigos de como las caractersticas
que antes solo posean los equipos de computo de alto desempe
no, se han
incorporado paulatinamente a los equipos mas peque
nos y comunes. En 1984
no haba modo de comparar una Apple Macintosh o una IBM PC AT con
una HP 9000, el desempe
no de la HP era muy superior al de las dos primeras, sus contempor
aneas. Pero con el paso del tiempo el desempe
no de las
computadoras personales ha ido acercandose, hasta finalmente superar, el de
las minicomputadoras y estaciones de trabajo, las que a su vez desplazaron
a los mainframes de anta
no.
Las mejoras tecnol
ogicas y la disminucion de costos han hecho posible incorporar en peque
nos microprocesadores lo necesario para dotarlos de
pipeline, caches, buses veloces, y demas. Los procesadores de las computadoras personales se parecan cada vez mas a los CPUs de las maquinas
grandes. Cuando, durante la decada de 1980, el paradigma RISC se adue
no
del mercado de alto desempe
no, los microprocesadores de equipos PC comenzaron a disfrazarse de RISC. Actualmente casi cualquier PC moderna
*

Departamento de Matem
aticas, Facultad de Ciencias, UNAM. jose@matem.unam.mx
Cray Research dej
o de existir hace poco, en 1997 fue absorbida por Silicon Graphics.
En buena medida las m
aquinas Origin son producto del equipo Cray en Silicon Graphics.
1

71

obtiene rendimientos comparables a los de las estaciones de trabajo RISC.


Las supercomputadoras han dejado de ser rentables, su nicho de sobrevivencia se mantiene difcilmente, clusters de equipos personales pueden obtener
rendimientos similares por una fraccion del costo.
Lo que hemos observado es que los desempe
nos de las diferentes categoras de equipos de computo se han ido acercando hasta hacerse casi
indistinguibles. La brecha se ha reducido.
Pero ahora que sigue? como se puede mejorar el desempe
no a
un mas?
Hay dos posibilidades [6]:
1. Haciendo las operaciones mas rapido. Esto depende esencialmente de la
tecnologa de semiconductores y de metodos de dise
no que minimicen
los niveles de l
ogica digital necesarios para hacer las operaciones.
2. Haciendo m
as cosas al mismo tiempo. Esto es, incrementar, en la medida de lo posible el paralelismo a nivel de instrucciones (ILP o Instruction Level Parallelism). Hacer muchas instrucciones o trozos de
ellas al mismo tiempo, algo que se logra parcialmente con pipeline,
pero que se puede hacer a
un mejor.
Luego de exito obtenido por Intel en 1971 con el primer microprocesador,
el 4004, una compa
na fabricante de terminales para mainframes, Datapoint,
solicit
o a Intel el dise
no de un microprocesador para ser incorporado en
sus terminales. La respuesta de Intel fue el primer procesador de 8 bits,
el 8008 (1972), que contena todo lo necesario para manejar la logica de
una terminal, sus 8 bits e instrucciones especficas para manipular datos en
c
odigo ASCII y BCD, le hacan posible manipular los caracteres enviados
desde y hacia la computadora, tambien posea instrucciones especficas para
manipular cadenas.
En 1974 sali
o al mercado el Intel 8080, otro procesador de 8 bits compatible con el 8008 pero que incrementaba las capacidades de este, por ejemplo,
poda direccionar m
as memoria (64Kb. contra los 16Kb. del 8008). En 1978
sale el Intel 8086 y en 1979 el 8088 ambos de 16 bits y casi identicos (salvo
el tama
no del bus de datos y el de la cola de prefetch). Por supuesto ambos podan ejecutar las mismas instrucciones del 8080, que a su vez poda
ejecutar las del 8008, y muchas mas. El 8088 fue el procesador elegido por
IBM para su linea de computadoras personales en 1980 y esa decision ha
marcado en buena medida las u
ltimas dos decadas en equipo de computo.
Generaci
on tras generacion los procesadores de Intel para equipo de
computo personal han mantenido la lnea se
nalada por el 8086/8088. El

72

poco conocido 80186, el 80286, 80386, 80486 y la familia Pentium son capaces de ejecutar a
un las instrucciones de un 8008. Esas extra
nas operaciones aritmeticas con c
odigos ASCII y BCD y de manejo de cadenas siguen
all. Esto ha sido una espada de doble filo. Por una parte Intel siempre ha
garantizado que lo que se invierta en software no sera una inversion perdida, si se compra un programa para una IBM PC XT se podra ejecutar
en una AT, una 386, una con Pentium III. Por otra parte Intel ha tenido
que redise
nar sus procesadores para competir en un mercado en constante
evoluci
on, sobrevivir contra los dise
nos RISC, competir con ellos y hasta vencerlos en desempe
no no ha sido facil, seguramente todo ha sido mas difcil
dado que siempre han tenido que cargar con el pesado fardo de las mas
primitivas m
aquinas CISC, con el desorganizado conjunto de instrucciones
que creci
o an
arquicamente, como una enfermedad degenerativa que hay que
arrastrar.
Aparentemente las cosas estan por cambiar. Cuando Intel anuncio en
1999 su nueva arquitectura IA-64 (Intel Architecture 64 bits), anuncio tambien su ruptura con el pasado y de hecho con buena parte del presente.
El Itanium, el primer procesador de IA-64 tiene un nuevo conjunto de instrucciones, no es ya una m
aquina CISC, para ejecutar el codigo que podan
ejecutar sus ancestros tendra que traducir las instrucciones mediante hardware especfico para tal proposito. Esto hara, en principio, la ejecucion de
programas viejos m
as lenta, de hecho mas lenta de lo que sera su ejecucion en
la arquitectura de Intel que mantendra la estirpe de 80X86 (IA-32 de la que
el pentium 4 es el m
as reciente representante). Literalmente se dice [7] Para
obtener un m
aximo desempe
no en IA-32 debe considerarse fuertemente la
arquitectura de Intel IA-32 en vez de IA-64.
As que la arquitectura del Itanium, IA-64, no sera CISC (de hecho las
u
ltimas generaciones de Intel IA-32 ya no pueden considerarse CISC). Tampoco es RISC, m
as bien es del tipo VLIW (Very Large Instruction Word),
aunque Intel prefiere decir que es EPIC [2] (Explicitly Parallel Instruction
Computing, siempre es bueno ponerle otro nombre a las cosas, sobre todo
si hay que pagar derechos de patente). VLIW o EPIC como prefiere Intel,
es el paradigma id
oneo para incrementar el ILP. La segunda de las dos alternativas mencionadas para elevar el desempe
no y que implica a
un mas
colaboraci
on compilador-arquitectura.
Con las arquitecturas RISC que poseemos actualmente y las CISC que
sobreviven incorporando cualidades RISC es ya difcil obtener mas ILP. El
procesador no sabe ni puede saber, ni tiene por que saber, todo lo necesario
para lograr m
as paralelismo. Quienes si saben lo necesario por poseer una
visi
on m
as global, son los compiladores y los sistemas operativos. Mucho
73

del trabajo necesario para lograr sistemas de computo de mayor desempe


no
recaer
a en el software del sistema y en su perfecta coordinacion con el hardware.

2.

Dos t
ecnicas para incrementar el paralelismo

IA-64 incorpora dos tecnicas hasta ahora poco explotadas para incrementar el paralelismo a nivel de instruccion, ambas deben ser usadas explcitamente por los compiladores que generen codigo para IA-64 [1]: especulacion
y predicaci
on.
La especulaci
on consiste en hacer por adelantado algo que se considera
muy probable que ocurra. Consideremos el siguiente codigo en una maquina
load-store, supongamos ademas que el if es casi siempre verdadero y que el
registro R14 est
a disponible.
; if (!a) a=b; else a+=4;
LW
R1, (R3)
;
BNEQZ R1, salto1
;
LW
R1, (R2) ; a=b,
J
salto2
salto1: ADD
R1, R1, 4
;
salto2: SW
R1, (R3)
;

R3 direccci
on de a
si R1 no es cero salto1
R2 direcci
on de b
a+=4
guarda R1 en a

haciendo especulaci
on, suponiendo que la parte del if casi siempre se
ejecuta podemos hacer lo siguiente:
1
2
3
4
5
6

; if (!a) a=b; else a+=4;


LW
R1, (R3)
LW
R14, (R2)
BEQZ R1, salto2
ADD
R14, R1, 4
salto2: SW
R14, (R3)

;
;
;
;
;

a en R1
b en R14
si R1(a) es cero salto2, R14 tiene b
si a no es cero sobreescribimos en R14
guarda R14 en a

Esta transformaci
on es redituable si es muy frecuente ejecutar el codigo
de la parte if de la instruccion, de ser as podramos de hecho cargar a y
b con suficiente anticipaci
on y distanciando ambos LW de tal forma que no
se atore el pipeline. El u
nico que puede saber lo necesario para hacer una
transformaci
on as es el compilador, asi que es el quien debe especular.
Pero imaginemos que en la segunda version del codigo presentado arriba,
ocurre un error al acceder a la localidad apuntada por R2 en la lnea 3.
Estamos en problemas, la lnea 3 es pura especulacion, quizas ni siquiera
debimos acceder a la localidad (R2), porque en la ejecucion del programa,
la variable a es cero. Eso no lo puede saber el compilador porque es algo que
74

ocurre en tiempo de ejecuci


on, as que debe haber intervencion del hardware
para resolver el problema.
En IA-64 en particular y en general en las arquitecturas con soporte
para especulaci
on, se provee de mecanismos para verificar si lo que se hizo
fue correcto o no. Las instrucciones que hacen especulacion se diferencian y
luego pasan por una verificacion que se encarga de que ocurra justo aquello
que hubiera ocurrido de ejecutar el programa original. En nuestro ejemplo la
instrucci
on de la lnea 3 debe ser marcada, si es un error acceder a (R2) hay
que esperar hasta ver si se ejecuta la lnea 6 en ese caso el error realmente
debe ocurrir, si en cambio se ejecuta la lnea 5 hay que tomar las acciones
pertinentes para corregir el error. Esto se hace insertando una instruccion
especial para verificar los datos cargados especulativamente.
En un Itanium una carga no especulada [4] se vera as:
1
2
3

br.cond.spkt L1
ld8 r3=[r5]
add r7=r3,r87

; salto condicional a L1
; carga 8 bits
; suma r3+r87 en r7

Si suponemos, conservadoramente, que la latencia de memoria es de dos


ciclos entonces la secuencia de arriba produce un atoron de 1 ciclo en la lnea
3. Especulando:
1
2
3
4
5

ld8.s r3=[r5]
; carga 8 bits, especulaci
on
; otras instrucciones
br.cond.spkt L1 ; salto condicional a L1
chk.s r3, recuperacion ;
add r7=r3,r87
; suma r3+r87 en r7

donde recuperacion es la etiqueta asociada a la instruccion de inicio


de la rutina de recuperaci
on para esta especulacion en particular, codigo
generado por el compilador. sptk significa que el salto es estaticamente
predicho como tomado (static predicted taken).
Otra tecnica que favorece el paralelismo es la predicacion. Normalmente
cuando el procesador se topa con un salto debe predecir si este sera tomado
o no, s la predicci
on resulta incorrecta habra que hacer flush tirando a la
basura lo que se haya cargado en el pipeline luego de la instruccion de salto,
el trabajo ya hecho sobre el codigo cargado incorrectamente de pierde, a
mayor longitud del pipeline la perdida es mayor.
La tecnica de predicaci
on permite incluso eliminar saltos. Consideremos
el siguiente c
odigo en un Itanium;
1
2
3

; if (r1) r2 = r3 + r4;
; else
r7 = r6 - r5;
cmp.eq p1,p2=r1,0 ; p1=(r1==0)

75

4
5
6
7
8

(p1)

cero:
final:

br.cond cero
add r2=r3,r4
br final
sub r7=r6,r5

En la lnea 4 se prueba el resultado de la comparacion de la lnea anterior.


De ser verdadero que r1 es cero entonces p1 es verdadero. p1 es lo que se
conoce como un predicado, es verdadero o falso de acuerdo con el resultado
de la comparaci
on que le asigna su valor. Entonces en la lnea 4, si p1 es
verdadero se lleva a cabo el salto a cero de otro modo se ejecutan las lneas
5 y 6. p2 es tambien un predicado y es el complemento de p1. El salto de la
lnea 5 debe predecirse.
Ya que tenemos predicados podemos aprovecharnos de ellos y escribir
todo como sigue:
1
2
3
4
5

; if (r1) r2 = r3 + r4;
; else
r7 = r6 - r5;
cmp.eq p1,p2=r1,0 ; p1=(r1==0)
(p1)
sub r7=r6,r5
(p2)
add r2=r3,r4

Con esta traducci


on es posible insertar algunas instrucciones entre las
lneas 3 y 4 que haya que hacer de todos modos y entonces nunca perdemos
el tiempo, no tenemos que predecir ni correr el riesgo de equivocarnos. El
Itanium posee 64 registros de 1 bit para guardar predicados (formalmente
hablando las evaluaciones de predicados) [4].

3.

Unidades funcionales

El Itanium posee 9 unidades funcionales paralelas (superescalar) todas


ellas con pipeline [3]:
Dos unidades de acceso a memoria (calculo de direcciones, load, store).
Dos unidades de ejecucion de operaciones con enteros.
Dos de ejecuci
on de operaciones de punto flotante y multimedia
Tres de ejecuci
on de saltos.
Las instrucciones de IA-64 estan divididas en cuatro categoras:
I Operaciones con enteros.
76

Figura 3.1: Dispersi


on de bundles (ternas de operaciones) en las unidades
funcionales del Itanium. La tercera terna no puede ser completamente distribuida, as que debe esperar un ciclo de reloj.
F Operaciones con n
umeros en punto flotante.
M Operaciones de acceso a memoria.
B Saltos.
Cada categora, como puede apreciarse corresponde a un rubro distinto de
las unidades funcionales descritas arriba. As que pueden ser despachadas
al mismo tiempo diferentes instrucciones a diferentes unidades funcionales.
De hecho el Itanium maneja grupos de tres instrucciones, lo que Intel llama
bundle y que en terminologa mas usual es la palabra de instrucciones de una
arquitectura VLIW. Cada palabra de instruccion o bundle consiste de tres
operaciones elementales de algunas de las categoras mencionadas, es labor
del compilador procurar que los bundles esten construidos de tal forma que
no ocurran, en la medida de lo posible, hazards de datos, que se llenen la
mayor cantidad de unidades funcionales y que no ocurra hazard estructural
cuando ya no alcanzan las unidades funcionales de alg
un tipo.
Para auxiliar al compilador el Itanium procesa una ventana de dos bundles y es capaz de hacer algo llamado rotacion en caso de que las unidades
funcionales no alcancen. Supongamos la situacion en la que son enviados los
cinco bundles que se observan en la figura 3. Los primeros dos de la primera
ventana no tiene problema. Pero cuando se toma la segunda ventana ya no
alcanzan las unidades de enteros, as que hay que esperar un ciclo de reloj y
mover la ventana, no al siguiente par de bundles como se hubiera hecho en
condiciones ideales, sino solo un bundle mas.
Como consecuencia del manejo de bundles a traves de la ventana de
ejecuci
on el Itanium tiene un throughput maximo de 6 instrucciones por
ciclo de reloj.

4.

Caractersticas

Como ya se dijo antes, el desempe


no del Itanium dependera, mas de
lo usual, de la correcta relacion entre el software y el hardware [1]. Los
compiladores, a traves de instrucciones especficas para ello, tendran control
total, si asi lo desean, sobre la prediccion de salto, el orden de las operaciones,
la predicaci
on y la especulacion. En particular el compilador puede decidir,
77

como en uno de nuestros ejemplos previos, si un salto debe ser predicho


est
aticamente o din
amicamente con base en su historial. Tambien puede
decidir si un salto debe ser predicho tomado o no tomado, en caso de ser
est
atica la predicci
on. El Itanium posee el hardware necesario para poder
ofrecer estas facilidades al compilador. En particular posee diversas tablas
relacionadas con saltos [3]:
BPT (Branch Prediction Table) y MBPT (Multiway Branch Prediction
Table). Ambas para predecir dinamicamente si seran o no tomados
los saltos, cada tabla se encarga de diferentes tipos de bundles. Por
ejemplo la BPT se ocupa de los saltos contenidos en ternas del tipo
MMB mientras que la MBPT se encarga de los MBB o BBB (ternas
con m
as de un salto en general). Ambas tablas son asociativas de
conjunto de 4 opciones
TAR (Target Address Register ) una tabla de cuatro entradas manipulada directamente por el compilador para especificar la direccion de
saltos predichos est
aticamente y TAC (Target Address Cache) una tabla de 64 entradas responsable de proporcionar la direccion de salto
para los predichos dinamicamente.
Una pila de direcciones de retorno.
El Itanium poseer
a tres niveles de cache, L1 y L2 en el chip y L3 exterior.
el cache L1 ser
a asociativo de conjunto de 4 opciones con bloques de 32 bits
capaz de hacer dos accesos por ciclo con latencia de dos ciclos, write throught
y no-write allocate [3]. El nivel L1 esta dividido en datos y codigo.
El cache de nivel L2 es unificado, asociativo de conjunto de 6 opciones,
write back y write allocate con bloques de 64 bytes, dos accesos por ciclo con
latencia de 6 a 9 ciclos.
Adicionalmente el Itanium posee buffers de traduccion de direcciones
reales a direcciones de cache, para evitar tener que traducir direcciones reales
a direcciones de cache todo el tiempo, basandose en el principio de localidad. Para ello posee dos niveles de buffers de traduccion de direcciones o
TLBs (Translation Lookaside Buffer ) para datos. Ambos completamente
asociativos. El TLB de datos de nivel L1 tiene 32 entradas y el de nivel L2
tiene 96 entradas. El TLB de codigo es de un solo nivel y es completamente
asociativo de 64 entradas.
El Itanium posee 128 registros de proposito general de 64 bits y el mismo n
umero de registros para punto flotante. 64 registros de un bit para
predicados [2, 4].
78

Adicionalmente tiene registros para manejo de saltos, unos obscuros registros de aplicaci
on, registros para monitoreo de desempe
no y registros de
identificaci
on de la versi
on de IA-64 implementada que identifican al procesador (CPUID).
Los registros de prop
osito general poseen un bit adicional (i.e. en realidad
son de 65 bits), este sirve para indicar si el estado del registro es valido o no,
algo u
til cuando se hace reordenamiento de instrucciones, este bit se llama
NaT (Not A Thing).

Referencias
[1] Zahir, Rumi, J. Ross, D. Morris y D. Hess, OS and Compiler Considerations in the Design of the IA-64, en Computer Architecture News
ACM, 28(5), diciembre de 2000, pp. 212-221.
[2] Monson, Heidi, The Arrival of the 64bit CPUs, Itanium and Sledgehammer, en http://www.sysopt.com, octubre de 1999.
[3] Itanium Processor Microarchitecture Reference, Intel, marzo de 2000,
en http://www.intel.com.
[4] IA-64 Architecture Software Developers Manual, junio de 2000, en
http://www.intel.com.
[5] Intel Itanium (Merced) 64 bit, en http://www.geek.com.
[6] Diefendorff, Keith, PC Processor Microarchitecture, Microprocessor
Report, julio 12, 1999.
[7] Inside Intels Merced: An Executive White Paper, Intel, julio 1999.

79

Você também pode gostar