Diseño y construcción de computadoras paralelas

mexicanas

Adolfo Guzmán Arenas

Centro de Investigación en Computación, Instituto Politécnico Nacional, México
a.guzman@acm.org

RESUMEN. He tenido la suerte de participar en el diseño y manufactura de máquinas que

contienen varios procesadores, llamadas por eso multiprocesadores o computadoras parale-
las, puesto que ejecutan al mismo tiempo varios programas. La construcción exitosa de es-
tos equipos sigue ciertos principios y reglas, y requiere de simulación y depuración cuida-
dosas. En el desarrollo he descubierto cómo resolver ciertos problemas: el de paralelizar un
programa simbólico, o el de convertir un multiprocesador de tipo “todos hacen lo mismo”
(SIMD) en otro de tipo “cada quien hace algo distinto” (MIMD) sin necesidad de cambiar
el hardware (la electrónica). La narración es descriptiva, parca en detalles técnicos.

1. EL MULTIPROCESADOR AHR Y SUS DESCENDIENTES

Alrededor de la década de 1971, varios grupos en México buscaron construir una com-
putadora, es decir, un sistema con procesador, memoria, periféricos, sistema operativo y ca-
nales de comunicación, que fuese de propósito general. Un intento exitoso que conozco es
el de la computadora IPN-32, que Miguel Lindig construyó en UPIICSA basado en el chip
(circuito integrado de alta densidad) Intel 80286. Es esencialmente una PC que usa Unix
como sistema operativo.
Ha habido otros intentos en México, los que no mencionaré.

1.1 Multiprocesadores y la necesidad de paralelizar programas

Estas máquinas con un solo procesador se llaman por eso monoprocesadores, y ejecutan
un solo programa a la vez. Un multiprocesador puede ejecutar varios programas simultá-
neamente, uno por cada procesador que tenga.1 Para esto, hay dos maneras de proceder:
(1) todos los procesadores ejecutan el mismo programa, pero sobre diferentes conjuntos de
datos. Imagine una parte de una obra de ballet donde las bailarinas ejecutan los mismos
movimientos: todas ellas levantan la pierna izquierda; luego, todas giran a su derecha...
Se les conoce como del tipo SIMD («single instruction, multiple data»).
(2) Cada procesador ejecuta un programa distinto. Imagine una parte del ballet donde una
bailarina brinca, otra gira mientras que una tercera permanece inmóvil... Se les conoce
como del tipo MIMD («multiple instruction, multiple data»). Estas máquinas son más
versátiles que las del tipo MIMD, se usan en mayor número de problemas, pero requie-
ren que el programador escriba varios programas y los sincronice para que el resultado
de su ejecución sea el deseado. Es más fácil escribir la coreografía de una obra donde
las diez bailarinas hacen lo mismo, que una coreografía donde cada quien ejecuta distin-
tos movimientos: habrá que describir (documentar) diez ejecuciones individuales, y
1
Una máquina paralela con n procesadores es más rápida que una con un solo procesador. Esta es su principal
ventaja. Pero raras veces es n veces más rápida. Su ganancia en rapidez es menor que n.

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 1 de 9

 añadir puntos de sincronización de modo que cuando dos brinquen las otras ocho se
agachen... Esto hace que el trabajo del programador se vuelva muy pesado, pues crece
proporcionalmente con el número de procesadores que va a usar simultáneamente.
Una manera de sacarle buen provecho a un procesador tipo MIMD, es inventar un mé-
todo o algoritmo que tome un solo programa (no muchos como en (2) arriba) escrito por al-
guien, y lo reparta de alguna manera (lo paralelice) entre los varios procesadores del multi-
procesador. En 1976, Cook [1.] en Illinois inventó un método útil en muchos casos para
programas numéricos, repetitivos, que trabajan con matrices y vectores. Es útil para progra-
mas que repiten los mismos cálculos sobre muchos datos, como la iteración o repetición de
operaciones que indica el postulado DO del lenguaje Fortran. Mediante un análisis cuidado-
so de los índices de arreglos y matrices que aparecen en el programa a paralelizar, es posi-
ble decidir qué partes del programa pueden repartirse entre cuáles procesadores, los que en-
tonces realizan cálculos de manera independiente, con escasa comunicación entre ellos.
Pero no se conocía algoritmo alguno para paralelizar programas que carecieran de índi-
ces. Ni para programas que operaran sobre objetos simbólicos, 2 no numéricos. Este no se
resolvió sino hasta 1976 [1.] como describo a continuación.

1.2 Cómo paralelizar un programa simbólico

Cuando los cálculos sobre datos simbólicosError: Reference source not found son ex-
tensos, conviene usar un multiprocesador. Esto requiere paralelizar el programa que hace
los cálculos. El problema en general es que un procesador i va a requerir para continuar su
trabajo, de algunos resultados parciales calculados por otros procesadores j, k,.. Si el proce-
sador i ya acabó su trabajo antes de j, k,..., debe esperar a que todos ellos acaben. Es tiempo
desperdiciado: el procesador i no puede continuar porque otros se lo impiden. Este proble-
ma lo resuelve la máquina AHR (§1.3) donde ningún procesador espera. La solución se re-
vela en el siguiente ejemplo.
1.2.1 Ejemplo: un edificio en construcción con un pizarrón
Un proceso paralelo generalmente usa un árbitro o “director ejecutivo” que distribuye
trabajo. En una obra en construcción, podría ser el arquitecto responsable. Llegan a él los
albañiles, carpinteros y otros trabajadores especializados en busca de trabajo. Él los dirige y
les dice qué hacer. Esto es un sistema jerárquico, donde hay un “director de orquesta” que
dice a cada quien qué hacer cuándo. El problema con sistemas jerárquicos es que el director
de orquesta puede ser un cuello de botella, si varias peticiones de trabajo le llegan casi si-
multáneamente. Tiene que atender cada petición en secuencia (serializa las peticiones). ¿Es
posible eliminar al director de orquesta, y diseñar otro sistema donde la construcción proce-
da aunque el director de orquesta (arquitecto responsable) esté ausente? ¿Puede haber una
orquesta sin director de orquesta? ¿Una iglesia católica sin Papa? Se tendría entonces un
sistema heterárquico (sin jerarquía), donde “cada quien hace lo que es menester” y no hay
retrasos. La respuesta es “sí”, y la encontré en 1973 y publiqué en 1976 [4.]. La explico:
Para el caso de la obra en construcción, el arquitecto responsable diseña la construcción
de la obra, dividiéndola en trabajos elementales 3 donde se especifica claramente qué hay
que hacer (resultados a obtener) y qué datos o condiciones ya deben estar disponibles. Por
2
La mayoría de los objetos que las computadoras manejan son simbólicos, no numéricos: la dirección (URL) de una
página Web, el nombre de un cliente, su religión, su dirección, sus aficiones, los guisos en un restaurante...

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 2 de 9

ejemplo, para el trabajo elemental ‘colocación de puertas’ el resultado es ‘puertas coloca-
das’ y los prerrequisitos son ‘paredes terminadas y enyesadas o aplanadas.’ Para el trabajo
elemental ‘colocar muebles de baño’ el prerrequisito es ‘tuberías y drenaje ya instalados.’
El arquitecto escribe estos trabajos elementales en tarjetas o fichas que coloca en la obra en
un tablero o pizarrón. Además, cada tarjeta señala a las otras tarjetas que están esperando el
resultado de esta tarjeta; o sea, que tienen como prerrequisito el resultado de esta tarjeta.
Por ejemplo, la tarjeta ‘instalar tuberías de agua’ señala a la tarjeta ‘colocar muebles de ba-
ño’, porque esta segunda tarjeta requiere de la instalación de tuberías para poder proceder.
También la tarjeta ‘instalar drenaje’ apunta a la tarjeta ‘colocar muebles de baño’ por la
misma razón. Este trabajo de convertir un programa a otro “con tarjetas de trabajo elemen-
tal” lo realiza en la máquina AHR un compilador (realmente, un lector o cargador) cuando
el programa que especifica los cálculos entra por primera vez al multiprocesador.
Hecho esto, el arquitecto le dice a cada trabajador: “ve al pizarrón y busca algún trabajo
(alguna tarjeta) listo para llevarse a cabo, retira la tarjeta y hazlo. Cuando lo termines, irás a
las otras tarjetas apuntadas por tu tarjeta, y señalarás en ellas que tu trabajo ya ha sido he-
cho. Y buscarás más trabajo que puedas hacer. Eso es todo.” Y el arquitecto se retira a des-
cansar (o se dedica a otras tareas distintas de administrar la construcción).4
En la máquina AHR se hizo otra extensión importante: cada procesador puede ejecutar
cualquier operación elemental. Es como si los trabajadores de una construcción fueran uni-
versales: cualquiera puede realizar cualquier trabajo elemental: hacer zanjas, colocar puer-
tas...
Llegan los trabajadores (universales), el terreno está virgen, no hay construcción aún.
Van al pizarrón y buscan trabajos. Los únicos trabajos listos para hacer son ‘cavado de zan-
jas’ puesto que tienen como prerrequisito ‘nada.’ Conforme alguien termina de cavar la
zanja norte, indica en las tarjetas ‘colocar cimiento de la sala’ y ‘colocar cimiento del co-
medor’ la condición ‘ya hecha: zanja norte’. De modo que el trabajo ‘colocar cimiento del
comedor’ ya puede realizarse. Por alguien más. O por el mismo trabajador que acaba de ter-
minar su cavado de la zanja norte.
Según este régimen de operación, ningún trabajador espera. Todos toman trabajo que
están seguros de poder realizar, pues los prerrequisitos de estos trabajos están satisfechos.
Nótese que si algún trabajador está inactivo, es porque en realidad no hay trabajo por
hacer. La construcción termina cuando todos los trabajadores se aglomeran en el pizarrón,
y éste está vacío, sin tarjetas: el trabajo ha concluido.
El pizarrón elimina el sistema operativo. No hay director de orquesta. El sistema fun-
ciona de modo heterárquico.
Una vez que entendimos cómo se podía paralelizar un programa simbólico, quisimos
ser los primeros en el mundo en hacerlo, y construimos el multiprocesador del §1.3.

3
Un trabajo elemental puede considerarse indivisible, y será ejecutado por un solo procesador (un carpintero,
digamos)
4
Las referencias al fin de este articulo describen cómo se maneja la recursión: cuando la ejecución de un trabajo
requiere solicitar trabajo adicional. Por ejemplo, un trabajador que coloca un mueble de baño necesita que alguien
más levante un muro (que no estaba explícitamente contemplado en el diseño original que el arquitecto escribió en el
pizarrón). Este nuevo “muro que surge de necesidades” se especifica en una nueva tarjeta el colocador de muebles
de baño, y la agrega al pizarrón, “para que alguien más lo construya.”

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 3 de 9

1.3 La construcción de un multiprocesador que usa Lisp como lenguaje
principal: la máquina AHR
La máquina AHR [5., 6., 7.], propuesta en 1973 en México, D. F. y operacional en
1981, proporcionó datos que ayudaron a establecer que sería práctico construir computado-
ras paralelas para procesamiento no numérico. Su nombre es un acrónimo de Arquitecturas
Heterárquicas Reconfigurables, enfatizando su arquitectura reconfigurable y de un solo ni-
vel (heterárquica). AHR ejecuta Lisp puro en paralelo. Cada microprocesador puede ejecu-
tar cualquier primitiva de Lisp, y la computadora puede tener hasta 64 microprocesadores
del tipo Z80A. Cada uno tiene su memoria privada, y todos comparten acceso a tres memo-
rias comunes: (1) la parrilla, donde reside el programa Lisp que se está ejecutando; (2) la
memoria pasiva, que contiene datos, y (3) la memoria de variables, donde se tienen las va-
riables y sus valores, en forma de una lista (Alist, o «association list»). Un pizarrón, imple-
mentado como un FIFO, despacha trabajos a los procesadores que lo solicitan. Al usar Lisp
puro, el programador no necesita percatarse de que el programa que él escribe se estará eje-
cutando en paralelo. No es necesario escribir comandos paralelos explícitamente. Toda la
comunicación con el usuario es a través de una máquina anfitriona, para la cual AHR es un
procesador de fondo («background processor»).
La arquitectura de AHR se basa en varias premisas. El sistema operativo es pequeño de-
bido a la sincronización entre procesos que el mismo hardware realiza, mediante simples
contadores. Ningún proceso se necesita comunicar explícitamente con algún otro. Un pro-
cesador nunca se bloquea mientras aún haya trabajo por hacer. Un procesador puede proce-
der sin desperdiciar tiempo alguno. Además, un proceso mismo nunca se bloquea: o bien
no ha empezado, o si está ejecutando, corre hasta completar. Finalmente, la arquitectura
AHR se construyó (figuras xx y zz), y trabajó según se predijo [8.].
1.3.1 Descendientes del multiprocesador AHR
La máquina PS-2000*. Durante la construcción de AHR tuvimos la suerte de que el Prof.
Kemer B. Norkin, del afamado Instituto de Ciencias del Control (Institute of
Control Sciences) nos visitara, se interesara y participara en la construcción de
AHR. Terminada, surgió la posibilidad de transplantar este diseño a la Unión Soviética.
De modo que en 1982 visitamos Moscú Miguel Gerzso y yo, para adaptar una computa-
dora que ellos ya habían construido (la PS-2000), a fin de hacerla trabajar según el régi-
men de AHR. Esto dio origen a la máquina del §1.4.
Las arquitecturas paralelas de MCC. En 1981 comenzó el Proyecto Japonés de la Quinta
Generación, que buscaba construir máquinas muy avanzadas, paralelas, y que hicieran
cálculos simbólicos y lógicos. Las empresas estadounidenses se preocuparon, por lo que
fundaron el centro de investigación privado MicroElectronics and Computer Corpora-
tion en Austin, TX, para hacer investigación avanzada y atrevida sobre hardware y so-
ftware, capaz de producir máquinas que compitiesen con las de quinta generación japo-
nesas. Dada mi experiencia con AHR, me invitaron a colaborar con ellos. De suerte que
en 1986 empecé a trabajar en MCC en un nuevo multiprocesador (§1.5).
En el CINVESTAV hubo un nuevo diseño heterárquico [11.] en 1985, que no se constru-
yó.

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 4 de 9

1.4 En Moscú: Conversión de una multiprocesador SIMD en otro
MIMD
Estamos en 1982. El procesador soviético PS-2000 consta de 64 computadoras del tipo
de la DEC PDP-11 (lo que se llamaba entonces una minicomputadora). La meta era conver-
tirlo en un multiprocesador heterárquico, como AHR, al que llamo PS-2000*. A nuestra lle-
gada al Instituto de Ciencias de Control en Moscú ese verano, la sorpresa fue que la PS-
2000 era una computadora del tipo SIMD, donde cada procesador ejecuta en todo momento
la misma instrucción. ¿Cómo convertirla en un procesador del tipo MIMD, donde cada pro-
cesador ejecuta una instrucción distinta? Parecía imposible, sin modificar extensamente el
hardware. Pero precisamente un señalamiento del Prof. Norkin decía “no podrán modificar
la electrónica ni los canales de comunicación.” Parecía que nuestra visita en el verano sería
poco productiva técnicamente. Sin embargo, encontramos la solución.
La solución [9., 10.] consiste en desmenuzar el programa (como en §1.2.1) en sus ope-
raciones elementales.Error: Reference source not found Se tendrá en la parrilla (§1.3) un
programa en forma de árbol donde cada nodo es una operación elemental. Entonces, el pro-
grama que reside en la unidad de control (procesador escalar) de la PS-2000 busca en su
memoria (ahí coloqué la parrilla) 64 nodos que estén listos para ejecutar la operación ele-
mental del tipo A (digamos, sen x), y despacha estos trabajos a cada uno de los procesado-
res vectoriales. Cuando haya menos de 64 operaciones del tipo A por hacer, algunos proce-
sadores vectoriales ejecutarán ‘no-op’ (nada, o ‘paso esta vez’). De nuevo, se requiere que
cada operación q elemental terminada indique a las operaciones que apuntan a q que el re-
sultado ya está listo. Así se generarán nuevas tareas elementales listas para ejecutarse, 5 aun-
que no necesariamente del tipo A que estamos ejecutando ahora. Cuando haya pocas ins-
trucciones tipo A listas a ejecutarse (de modo que una gran mayoría de los 64 procesadores
ejecutan ‘no-op’), entonces el procesador escalar procede a buscar en la parrilla operacio-
nes elementales de tipo B, etcétera. El proceso termina cuando el procesador escalar no en-
cuentra operación a ejecutar. De hecho, el programa “se consume” y al final, ya no existe
(como es Lisp puro, el programa se convierte en el resultado). Por eso le llamamos la parri-
lla: es como si un pedazo de carne cruda se convirtiera en paralelo en un bistec. De esta
manera cada procesador ejecuta la misma operación, pero al mismo tiempo cada procesador
“hace algo distinto”, en el sentido de que esa operación pertenece a una parte distinta del
programa. Así es como la PS-2000, una máquina SIMD, emula la AHR, una máquina
MIMD.
Esta solución permeó el software que convierte la PS-2000 en la PS-2000*. Regresa-
mos a México en Sept. 1982 (concluido el diseño). Nuestros colegas en Moscú terminaron
la programación un tiempo después.

1.5 En Texas: La máquina paralela de MCC

MCC desarrolló investigación en máquins paralelas para manipular datos no numéricos.
Mi trabajo (19866-88) en MCC [12., 13., 14.] se abocó a simular en máquinas de Lisp va-
rias arquitecturas donde variaba la jerarquía (distribución) de memorias. Se contaba con un
poderoso simulador que tomaba un programa de Lisp, lo compilaba a instrucciones de má-
quina y simulaba éstas, en paralelo, tomando en cuenta tiempos de conexión, etc. Desafor-
5
Una instrucción elemental está lista para ejecutarse cuando todos sus argumentos ya están evaluados..

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 5 de 9

tunadamente, el apoyo económico a MCC de sus socios fundadores menguó, y MCC cance-
ló la División de Procesamiento Paralelo. La máquina no se construyó.

1.6 En EEUU: Máquinas de Lisp con un solo procesador

Cerca de 1980, más o menos simultáneamente con la construcción de la máquina AHR,
Richard Greenblatt y otros [2.] estaban construyendo en MIT una máquina de Lisp de un
solo procesador, basado en un chip que contiene un procesador de Lisp. De aquí salieron
las máquinas de Lisp de las empresas Symbolics, Lambda Machines y Texas Instruments,
que tuvieron un cierto éxito comercial pero luego decayeron sin dejar descendientes. De he-
cho las simulaciones en MCC (§1.5) fueron hechas en máquinas Lambda y Symbolics.
1.6.1 ¿Por qué no tuvieron éxito las máquinas de Lisp?
“La moneda mala substituye del mercado a la buena”, dice la Ley de Gresham en Eco-
nomía. De la misma manera, “para que una máquina especializada compita con éxito con
una máquina general, la primera debe ser un orden de magnitud más rápida, o más econó-
mica, o menos consumidora de energía, o algo” parece ser una ley que rige para máquinas
especiales. Por ese tiempo (1987) apareció el compilador de Kyoto Common Lisp, de distri-
bución gratuita, que hizo que las estaciones de trabajo Sun pudiesen ejecutar bien Lisp. En-
traron a competir contra las máquinas de Lisp. Aunque éstas fueron especialmente diseña-
das para ejecutar Lisp, la ley anterior causó que Sun las hiciera obsoletas.
1.6.2 Diseño y construcción de chips especializados en México
La máquina de Lisp (§1.6) de un solo procesador tenía a éste en un solo chip, al igual
que la AHR (§1.3), donde el procesador de Lisp era la microcomputadora Z80A con har-
dware adicional hecho por nosotros. Esta tarea de construir circuitos integrados específicos,
especiales, continúa en nuestra industria. En México, el CINVESTAV-Guadalajara ha ela-
borado un buen número de chips, casi todos ellos para firmas de alta tecnología.

2. OTRAS MÁQUINAS PARALELAS MEXICANAS

Describo brevemente otros proyectos de máquinas paralelas en los que he participado.

2.1 La máquina 1-CIC-16: un cluster de estaciones de trabajo

En 2001 decidimos sustituir la computadora paralela IBM SP-2 del CIC por otra de di-
seño más reciente, más poderosa. Una alternativa a comprar un equipo comercial era dise-
ñar y construir nuestra máquina. El Laboratorio de Electrónica Digital del CIC apoyaba esta
opción. La decisión se inclinó por construir un cluster de 16 estaciones de trabajo (servido-
res PC con bastante memoria y disco), unidas por un conmutador («switch») de alta veloci-
dad que efectuaba la transmisión de mensajes (datos) de un procesador a otro. Este conmu-
tador no se accedía mediante operaciones de entrada y salida (las que generan interrupcio-
nes que sacan de memoria principal 6 al proceso que solicita transmitir datos). En vez de
6
Sacar un proceso de memoria principal a memoria secundaria («swapping») y restaurarlo después toma de 50 a
100 milisegundos, por lo que el conmutador descrito ahorra gran cantidad de tiempo y resulta muy rápido en la
transmisión de información.

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 6 de 9

operaciones de E/S, se usa el canal de acceso directo a la memoria (DMA) del procesador.
El conmutador roba ciclos de memoria al procesador, éste se queda “congelado” mientras
el conmutador hace la transferencia entre la memoria del procesador congelado y la de al-
gún otro procesador, al que también congela. No hay interrupción a los procesadores invo-
lucrados. La ventaja de esto es que Unix no saca de memoria principal a los procesos impli-
cados. Antes de construir el nuestro, fuimos al Laboratorio de Investigación NEC en Prin-
ceton, NJ, cuyo subdirector entonces era David Waltz (anterior Director General de Con-
nection Machine Co.) quien nos dio acceso al diseño de sus clusters para entenderlos mejor.
La máquina se construyó en 2002 en el CIC (Osvaldo Espinosa) con 16 procesadores, y ac-
tualmente se encuentra en operación (ver figura xx).

2.2 En Querétaro; Medidores precisos de flujo

En 2003 tuve el agrado de participar en el diseño de una máquina rápida y precisa para
medir la cantidad de líquidos y gases que pasa por un tubo grande (como un oleducto). Es-
tas máquinas ya existían en el mercado, y de hecho Pemex las usa bastante. El CIATEQ de-
seaba un producto mexicano que fuese una alternativa a los existentes.
El líder fue el Dr. José Pineda: comunicación de datos, medición y sensores, electrónica
de acoplamiento, y diseño de la arquitectura de cómputo (que me tocó a mí). Los progra-
mas que calculan el flujo ya estaban hechos. Se usó el procesador digital de señales DSP
TMS320C5509 “A” de Texas Instruments, y de hecho necesitamos dos, por razones de re-
dundancia y confiabilidad [16.]. El CIATEQ está evaluando la conveniencia de construirlo.

2.3 Principales aportaciones de este trabajo

A. Paralelización del trabajo simbólico sin necesidad de árbitro (§1.2). Es posible construir
un multiprocesador sin administrador central de las tareas a realizar.
B. Construcción de un multiprocesador (§1.3) que opera según (A.).
C. Cómo convertir un multiprocesador tipo SIMD en otro tipo MIMD sin necesidad de
modificar el hardware (§1.4).

2.4 Conclusiones
Es factible construir máquinas paralelas, pero debemos atender la ley del §1.6.1.
Las computadoras aún procesan datos no simbólicos con menos generalidad, eficiencia y
con mucho menos hardware especializado que para procesar números. Hay bastante
brecha que cerrar.
Los procesadores más rápidos del mundo son actualmente los paralelos. El procesador IBM
Blue Gene L tiene un desfogue de 70.72 teraflops (trillones de operaciones de punto flo-
tante por segundo; marzo 2005), con 32,768 procesadores [3.] y 8 terabytes de memo-
ria. El segundo más rápido es el Columbia de Silicon Graphics, con 51.87 teraflops. El
tercero es el Simulador de la Tierra de NEC, con 35.86 teraflops. Mateo Valero está
construyendo en España el computador xxx que desfoga xxx teraflops.

2.5 Referencias
Mis trabajos, como {30}, pueden consultarse en http://alum.mit.edu/www/aguzman

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 7 de 9

1. Cook. University of Illinois.
2. Máquina de Lisp de R Greenblatt u otros.
3. IEEE Spectrum, Feb. 2005, página 15.
El multiprocesador mexicano AHR para Lisp
4. {30} Guzmán, A. and Segovia, Raymundo. A Parallel Reconfigurable LISP Machine.
(1976) Proceedings of the International Conference on Information Science and Sys-
tems, 207-211. August 19-24. University of Patras, Greece. Describe la estructura y ca-
racterísticas de un nuevo tipo de computadora que utiliza LISP como su lenguaje má-
quina y realiza tanto procesamiento en paralelo como es posible.
5. {47} Guzmán A. A Parallel Heterarchical Machine for High Level Language Process-
ing. (1981) In Languages and Architectures for Image Processing. M. J. B. Duff y S.
Levialdi (eds). Academic Press. 230-244. Also: Proc. 1981 International Conference on
Parallel Processing, 64-71.
6. {51} Guzmán, A. Computadora Mexicana de Procesamiento en Paralelo. Información
Científica y Tecnológica, Vol. 3, No. 48, 42-43. 1982. Artículo de divulgación.
7. {67} Guzmán A. AHR: A Parallel Computer for Pure Lisp. (1988) In Parallel Compu-
tation and Computers for Artificial Intelligence, J. S. Kowalik (ed.), 201-222. Kluwer.
Also: MCC Technical Report PP 355 86, MCC.
8. {53} Norkin, Kemer y Guzmán, Adolfo. Diseño y Construcción de una Máquina Para-
lela Heterárquica: Reporte final del proyecto AHR. (1982) Reporte técnico AHR 82 21,
Laboratorio AHR, IIMAS-UNAM. (En inglés)
Trabajos sobre el multiprocesador soviético PS-2000*
9. {56} Guzmán A., Gerzso, M., Norkin, K. B., and Vilenkin, S. Y. The Conversion via
Software of a SIMD Processor into a MIMD Processor. PS2000, an Array Processor,
becomes AHR, a general purpose LISP machine. (1985) In Computer Architectures for
Spatially Distributed Data, H. Freeman y G. Pieroni (eds), Springer-Verlag. 121-137.
10. {63} Guzmán A.; Gerzso, M.; Norkin, K.; Logunova, N.; Vilenkin, S.; y Kuprianov, B.
Diseño Funcional de un Intérprete Lisp para la Computadora PS-2000 SIMD. (1983)
Reporte Técnico AHR 83 24, IIMAS. En inglés.
Diseño de un nuevo procesador mexicano heterárquico
11. {61} Norkin, K. B., y Guzmán A. Especificaciones Funcionales y Diseño Preliminar de
HECTOR, una Heterarquía de Microprocesadores. (1985) Reporte Técnico. Departa-
mento de Ingeniería Eléctrica, CINVESTAV.
Arquitecturas paralelas en EE.UU
12. {68} McGehearty, P., and Guzmán A. Hierarchical Parallel Architectures for Sym-
bolic Processing. (1986) MCC. Technical Report PP-387-86.
13. {69} Guzmán A., Krall, E., McGehearty, P., and Bagherzadeh, N. Measurement of
Symbolic Applications on a Parallel Architecture. (1987) Tech. Rep. PP-076-87, MCC.
14. {70} Guzmán A., Krall, E. J., McGehearty, P. F., and Bagherzadeh, N. Performance of
Symbolic Applications on a Parallel Architecture. (1987) Technical Report PP-163-87,
MCC. Also: International Journal of Parallel Programming, 16, 3, June.
La construcción de un multiprocesador con Unix como sistema operativo
15. (LA CONSTRUCCION DEL 1-CIC-16 CLUSTER DE PCS)
Diseño de un multiprocesador para medir flujo de hidrocarburos

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 8 de 9

16. {157} Adolfo Guzmán. (2003) Computador de flujo con dos procesadores DSP “Texas
Instruments” modelo TMS320C5509A. Informe AGA 03.06.26, Proyecto 280157.
Reemplaza al Informe AGA 03.06.05. CIATEQ-CONACYT, Querétaro, México.

Diseño y construcción de computadoras paralelas mexicanas. Adolfo Guzmán Arenas. 04 jul. 05 9 de 9