CURSO DE ORDENADORES

Conceptos básicos de arquitectura

y sistemas operativos
Quinta edición
2a edición en Servicio de Publicaciones ETSIT-UPM

Gregorio Fernández

Escuela Técnica Superior de Ingenieros de Telecomunicación

Universidad Politécnica de Madrid
Primera edición: Septiembre 1994
Segunda edición: Febrero 1995
Tercera edición: Febrero 1998
Cuarta edición: Febrero 2003 (1a edición en Servicio de Publicaciones ETSIT-UPM)
Quinta edición: Diciembre 2004 (2a edición en Servicio de Publicaciones ETSIT-UPM)

©2004 Fundación Rogelio Segovia para el Desarrollo de las Telecomunicaciones

No está permida la reproducción total o parcial de este libro, ni su tratamiento informático, ni la trans-
misión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro
u otros métodos, sin el premiso previo y por escrito de los titulares del copyright.

ISBN: 84-7402-312-2
Depósito legal: TO-98-2005

Edita: Fundación Rogelio Segovia para el Desarrollo de las Telecomunicaciones

Ciudad Universitaria s/n
28040 Madrid

Imprime: Gráficas Aurora

 Tabla de materias

Prólogo XIII

Prefacio XVII

0. Modelos y niveles 1
0.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
0.2. Sistemas y modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
0.3. Función, estructura y proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
0.4. Ejemplos de sistemas y modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
0.5. Pragmática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
0.6. Jerarquías de abstracciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
0.7. Jerarquía de niveles para los ordenadores . . . . . . . . . . . . . . . . . . . . . . . . . . 24
0.8. Un último ejemplo: la «máquina de von Neumann» . . . . . . . . . . . . . . . . . . . . 28
0.9. Estructura y contenido del libro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
0.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
0.11. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
0.12. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
0.13. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
0.14. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Primera parte:
La máquina desnuda, o el nivel de máquina convencional 45

1. Símplez 47
1.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.2. Modelos estructural y procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.3. Modelo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

I
II Tabla de materias

1.4. Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.5. Suma de dos números . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
1.6. Construcción de bucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.7. Programas mutantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.8. Suma de cien números . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
1.9. Intercambio de los contenidos de dos zonas de memoria . . . . . . . . . . . . . . . . . . 62
1.10. Subprogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.11. Ensamblador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
1.12. Introducción a las comunicaciones con la periferia . . . . . . . . . . . . . . . . . . . . . 69
1.13. Crítica de la espera activa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
1.14. Comentarios sobre Símplez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
1.15. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
1.16. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
1.17. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
1.18. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
1.19. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2. Símplez+i4 81
2.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.2. Modelo estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.3. Modelo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.4. Modos de direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.5. Convenios simbólicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.6. Contando con X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.7. Punteros e índices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.8. Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.9. Comentarios sobre Símplez+i4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.11. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.12. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.13. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.14. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3. Variaciones sobre representación y procesamiento 101

3.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.2. Memoria principal y registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.3. Representación de los tipos elementales de datos . . . . . . . . . . . . . . . . . . . . . 104
3.4. Convenios sobre el orden de almacenamiento . . . . . . . . . . . . . . . . . . . . . . . 111
3.5. Operaciones de procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.6. Procesamiento de interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.7. Introducción al procesamiento simbólico . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.8. Tiempo de traducción, tiempo de carga y tiempo de ejecución . . . . . . . . . . . . . . . 120
3.9. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.10. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Tabla de materias III

3.11. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

3.12. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.13. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4. Variaciones sobre instrucciones y direccionamientos 131

4.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.2. Tipos de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3. Formatos de instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.4. Modos de direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.5. Direccionamientos relativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.6. Pilas y subprogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.7. Repertorios de instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.8. Medidas de prestaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
4.9. «RISC» y «CISC» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
4.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.11. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
4.12. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
4.13. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
4.14. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

5. Variaciones sobre la periferia 167

5.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.2. Tipos de periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
5.3. Tratamiento de la variedad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.4. Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.5. Memorias secundarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.6. ADM: justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5.7. ADM: modelos estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.8. ADM: modelos procesales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.9. ADM: modelos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
5.10. Procesadores periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
5.11. Comunicaciones entre ordenadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
5.12. Normalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.13. Sistemas abiertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.14. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.15. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.16. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.17. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.18. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

6. Algorítmez: la UCP 199

6.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.2. Modelo estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.3. Modelo funcional: formatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
IV Tabla de materias

6.4. Modelo funcional: instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

6.5. Modelo procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.6. Modos de direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.7. Lenguaje ensamblador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.8. Ensamblaje, montaje y carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.9. Suma de cincuenta números . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.10. Intercambio de dos zonas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
6.11. Ordenación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
6.12. Rutinas aritméticas y de conversión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.13. Consideraciones sobre los subprogramas . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.14. Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.15. Comentarios sobre Algorítmez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.16. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.17. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.18. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.19. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
6.20. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

7. Algorítmez: la periferia 249

7.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.2. Comunicación con los puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
7.3. Esquemas de interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
7.4. Consulta por software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
7.5. Rutinas de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
7.6. Consulta por hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
7.7. Controlador de interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
7.8. Controlador de disquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
7.9. Controlador de gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
7.10. Unidad de gestión de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.11. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
7.12. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.13. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.14. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.15. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

8. Regístrez 287
8.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
8.2. Modelos estructural y procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
8.3. Modelo funcional: formatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
8.4. Modos de direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
8.5. Repertorio de instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
8.6. Subprogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
8.7. Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
8.8. Comentarios sobre Regístrez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Tabla de materias V

8.9. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

8.10. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.11. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.12. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
8.13. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Segunda parte:
El interior de la máquina, o el nivel de microarquitectura 317

9. Componentes de los modelos estructurales 319

9.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
9.2. Ruta de datos y sistema de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
9.3. Componentes de las rutas de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
9.4. La memoria principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
9.5. Los periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
9.6. La ruta de datos de Símplez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
9.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
9.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
9.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
9.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
9.11. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

10. Elementos de los modelos procesales 339

10.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
10.2. Sobre los modelos procesales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
10.3. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
10.4. Modelo procesal de Símplez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
10.5. Cronogramas de Símplez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
10.6. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
10.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
10.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
10.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
10.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
10.11. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

11. Microsímplez 351

11.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
11.2. Un secuenciador cableado para Símplez . . . . . . . . . . . . . . . . . . . . . . . . . . 352
11.3. Control microprogramado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
11.4. La micromáquina de Wilkes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
11.5. Un secuenciador microprogramado para Símplez . . . . . . . . . . . . . . . . . . . . . 356
11.6. Microsímplez+i4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
11.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
VI Tabla de materias

11.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

11.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
11.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
11.11. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

12. Modelos en el nivel de micromáquina 365

12.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
12.2. Modelos estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
12.3. Modelos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
12.4. Modelos procesales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
12.5. Firmware y emulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
12.6. Estado actual de la microprogramación . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
12.7. Microprogramación, arquitectura y microarquitectura . . . . . . . . . . . . . . . . . . . 372
12.8. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
12.9. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
12.10. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
12.11. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
12.12. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

13. Microalgorítmez 377

13.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
13.2. Modelo funcional de la UCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
13.3. Ruta de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
13.4. Modelo procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
13.5. Modelos estructural y procesal de la unidad de control . . . . . . . . . . . . . . . . . . 391
13.6. Modelo funcional en el nivel de micromáquina . . . . . . . . . . . . . . . . . . . . . . 393
13.7. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
13.8. Hardware: generación de las direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . 405
13.9. Hardware: atención de interrupciones y cesión de buses . . . . . . . . . . . . . . . . . . 408
13.10. Hardware: generación de las microórdenes . . . . . . . . . . . . . . . . . . . . . . . . 410
13.11. Comentarios sobre los diseños de Símplez y Algorítmez . . . . . . . . . . . . . . . . . 412
13.12. Un Microalgorítmez versátil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
13.13. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
13.14. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
13.15. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
13.16. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
13.17. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419

14. Controladores subordinados 421

14.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
14.2. Controlador de la MP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
14.3. Controladores de periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
14.4. Controlador serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
14.5. Controlador de ADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Tabla de materias VII

14.6.Controlador de interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

14.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
14.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
14.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
14.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
14.11. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

15. Variaciones sobre microarquitectura 437

15.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
15.2. Variaciones en los modelos estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . 438
15.3. Encadenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
15.4. Alternativas para el sistema de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 445
15.5. Memoria organizada modularmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
15.6. Memoria asociativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
15.7. Memoria oculta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
15.8. Memoria virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
15.9. Jerarquía de memorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
15.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
15.11. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
15.12. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
15.13. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
15.14. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

16. Microrregístrez 469

16.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
16.2. Modelos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
16.3. La memoria oculta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
16.4. Modelo funcional de la UCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
16.5. Modelo estructural de la UCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
16.6. Modelo procesal de la UCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
16.7. Conflictos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
16.8. Conflictos estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
16.9. Conflictos de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
16.10. Subsistemas del modelo estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
16.11. Otras posibilidades para la implementación . . . . . . . . . . . . . . . . . . . . . . . . 489
16.12. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
16.13. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
16.14. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
16.15. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
16.16. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
VIII Tabla de materias

Tercera parte:
La máquina vestida, o los niveles de máquina operativa y máquina simbólica 493

17. Máquinas virtuales 495

17.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
17.2. Máquinas reales y virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
17.3. El nivel de máquina operativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
17.4. El nivel de máquina simbólica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
17.5. Otros programas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
17.6. La comunicación entre el ordenador y las personas . . . . . . . . . . . . . . . . . . . . 501
17.7. Definición y componentes de los sistemas operativos . . . . . . . . . . . . . . . . . . . 503
17.8. Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
17.9. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
17.10. Hebras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
17.11. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
17.12. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
17.13. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
17.14. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
17.15. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

18. Monoalgorítmez 519

18.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
18.2. Modelo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
18.3. Ocho llamadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
18.4. Ejemplos de uso de las macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
18.5. Otras llamadas al sistema de ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
18.6. Carga y ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
18.7. Errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
18.8. Modelo estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
18.9. Modelo procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
18.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
18.11. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
18.12. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
18.13. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
18.14. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

19. Núcleo de Monoalgorítmez 543

19.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
19.2. Algoritmos y estructuras de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
19.3. Mapa de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
19.4. Estructuras de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
19.5. La rutina de interrupciones de programa . . . . . . . . . . . . . . . . . . . . . . . . . . 549
19.6. El sistema de gestión de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
19.7. El sistema de gestión de ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Tabla de materias IX

19.8. Gestores de periféricos y rutinas de servicio . . . . . . . . . . . . . . . . . . . . . . . . 561

19.9. Comparación con sistemas reales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
19.10. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
19.11. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
19.12. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
19.13. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
19.14. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

20. Multialgorítmez 567

20.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
20.2. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
20.3. Modelo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
20.4. Modelo estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
20.5. Modelo procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
20.6. El distribuidor y el planificador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
20.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
20.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
20.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
20.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
20.11. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595

21. Modelos en el nivel de máquina operativa 599

21.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
21.2. Modelos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
21.3. Modelos estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
21.4. Modelos procesales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
21.5. Detalles de implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
21.6. Procesos y hebras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
21.7. Estados a evitar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
21.8. Comunicación entre procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
21.9. Sistemas operativos en red y distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . 616
21.10. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
21.11. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
21.12. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
21.13. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
21.14. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
21.15. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

22. Modelos en el nivel de máquina simbólica 623

22.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
22.2. Modelos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
22.3. Modelos estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
22.4. Modelos procesales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
22.5. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
X Tabla de materias

22.6. Lenguajes de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

22.7. Sentencias, procedimientos y funciones . . . . . . . . . . . . . . . . . . . . . . . . . . 630
22.8. Procedimientos y funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
22.9. Tipos estructurados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
22.10. Lenguajes declarativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
22.11. Entornos de programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
22.12. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
22.13. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
22.14. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
22.15. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
22.16. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

23. La máquina virtual Java: arquitectura 647

23.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
23.2. Visión de conjunto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
23.3. Modelo estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
23.4. Modelo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
23.5. Modelo procesal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
23.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
23.7. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
23.8. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
23.9. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
23.10. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

24. La máquina virtual Java: implementación 671

24.1. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
24.2. Implementaciones programadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
24.3. Una implementación microprogramada . . . . . . . . . . . . . . . . . . . . . . . . . . 674
24.4. Implementaciones cableadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
24.5. Comentarios sobre la JVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
24.6. El lenguaje C# y la plataforma .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
24.7. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
24.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
24.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
24.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
24.11. Ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693

Apéndices 695

A. Codificación, sistemas de numeración y aritmética binaria 697

A.1. Codificación de la información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
A.2. Sistemas de numeración posicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
A.3. Algoritmos para operaciones aritméticas . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Tabla de materias XI

A.4. Aritmética binaria con coma fija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702

A.5. Aritmética binaria con coma flotante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
A.6. Aritmética decimal con BCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
A.7. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
A.8. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
A.9. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712

B. El nivel de circuito lógico 713

B.1. Componentes, sistemas y modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
B.2. Puertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
B.3. Sistemas combinacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
B.4. Biestables y registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
B.5. Sistemas secuenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
B.6. Buses, puertas triestado y puertas de colector abierto . . . . . . . . . . . . . . . . . . . 731
B.7. Memorias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
B.8. Observaciones terminológicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
B.9. Notas históricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
B.10. Orientaciones bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734

C. Léxico 735
C.1. Español–Inglés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
C.2. Inglés–Español . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738

Referencias 741

Índice 759
XII Tabla de materias

Dado que voy a defender que éste es un libro ra-
ro y magistral, lo primero que tengo que hacer es
reproducir, para información del lector, las acep-
ciones que de la voz ‘raro’ admite el Diccionario
de la Lengua Española.
Raro, ra. (Del lat. rarus) adj. Extraordinario, po-
co común o frecuente. 2. Escaso en su clase o espe-
cie. 3. Insigne, sobresaliente o excelente en su lí-
nea. 4. Extravagante de genio o de comportamien-
to y propenso a singularizarse. 5. Que tiene poca
densidad y consistencia. Dícese principalmente de
los gases enrarecidos. 6. V. tierra rara. De raro en
raro. loc. adv. Raramente, de tarde en tarde.
Desglosaré en este prólogo la suma de las ca-
racterísticas infrecuentes que convierten a este li-
bro en un objeto tan raro, tan raro, que cumple en
su totalidad las tres primeras acepciones del Dic-
cionario y además es de los que aparecen muy de
tarde en tarde.
Empezar diciendo que es didáctico —o sea,
adecuado para enseñar— puede parecer una pero-
grullada, puesto que su propio título expresa que
se trata de un Curso. No creo, sin embargo, que
todos los libros escritos con la finalidad de ser usa-
dos como textos para un curso sean didácticos, y
podría dar muchos ejemplos. Por suerte para noso-
tros, éste es profunda y seriamente didáctico.
XIII
Prólogo
Sus cualidades didácticas se derivan de un po-
tente aparato textual y gráfico formado por unos
contenidos rigurosos y originales, envueltos en un
enfoque sistémico y en un tratamiento sistemático,
unificados sin desmayo del principio al fin. Del ri-
gor y la minuciosidad prefiero no hablar, porque lo
comprobará inmediatamente cualquier lector que
aborde el estudio del libro.
Su originalidad se sustancia en la aparición en
escena sucesivamente de una familia entera de or-
denadores ficticios, que surgen justamente cuando
se los necesita para mostrar de forma completa y
sin fisuras lo que es esencial en todo cuanto atañe a
los conceptos y técnicas de la estructura y de la ar-
quitectura de los ordenadores, y de la arquitectura
básica de los sistemas operativos. Ahí tenemos a
Símplez, a Símplez+i4, a Algorítmez, a Regístrez;
después, a sus correspondientes versiones micro-
programadas, y, por último, a las versiones en for-
ma de máquinas operativas. Estos ordenadores de
ficción van creciendo y haciéndose más comple-
jos y poderosos a medida que va creciendo y asen-
tándose el conocimiento del lector o alumno. To-
memos, por ejemplo, el nivel Algorítmez. Primero
nos visita Algorítmez, pelado, por así decirlo. Más
adelante, se le añade una micromáquina y se con-
vierte en Microalgorítmez. Luego, se inviste con
XIV
un sistema de monoprogramación y crece a Mo-
noalgorítmez, y ya, moderno y potente, dotado de
un sistema de multiprogramación, se transmuta en
Multialgorítmez.
Otros autores han utilizado estos artificios, pe-
ro nunca de una manera tan amplia y coherente.
Son máquinas imaginarias, simplificadas, aunque
hay que avisar, para que nadie se confunda, de que
están fortísimamente ancladas en la realidad (en
caso contrario, serían engañosamente didácticas).
A los hechos me remito con un par de ejemplos:
Regístrez es un ordenador RISC con arquitectu-
ra SPARC, arquitectura implantada en el mercado
y a punto de convertirse en norma. Y Multialgo-
rítmez está absolutamente inspirada en el sistema
UNIX. Por consiguiente, el planteamiento de un
curso basado en máquinas ficticias está muy aleja-
do de una originalidad caprichosa y une a las ven-
tajas ya mencionadas por lo menos otras dos. La
primera es que sus contenidos están relativamen-
te al abrigo de las bruscas mudanzas tecnológicas
que son el pan nuestro de cada día en la indus-
tria informática. Y en segundo lugar, que ofrece
un recurso nemotécnico insospechado, pero com-
probado: nuestros alumnos, al cabo de los años,
recuerdan todavía el EIT–1, el EIT–2 y el lenguaje
ENSAM, que fueron los ancestros de esta nueva, y
mucho más sofisticada y perfecta familia de mons-
truitos.
El enfoque sistémico me parece una de las con-
tribuciones más notables del libro. Un ordenador
es un sistema muy complejo, seguramente uno de
los sistemas artificiales más complejos que exis-
ten. Toda visión completa y pormenorizada de la
realidad de un ordenador es inabarcable para el ser
humano, pero no lo es una visión completa y razo-
nablemente abstracta. El ordenador se puede estu-
diar de una manera especializada, pongamos por
ejemplo, tomando como plano su realidad en tan-
to que máquina que procesa un determinado len-
Prólogo
guaje, y es posible profundizar en el conocimiento
sobre dicho plano, a costa, eso sí, de negarse las
otras facetas de su múltiple personalidad. En es-
te libro, el autor ha optado, muy acertadamente,
por proyectar una luz múltiple sobre el ordenador,
lo que arroja una imagen muy rica, organizada y
fructífera. La luz múltiple se compone de modelos
(funcionales, estructurales y procesales) y de jerar-
quías de abstracciones. Este enfoque se especifica
muy bien en la lección cero, donde además se ex-
plica todo el despliegue de la estructura y los usos
posibles de los contenidos del libro en coherencia
con el enfoque sistémico.
De lo escrito en el párrafo anterior podría de-
ducirse (apresuradamente) que el autor habría ele-
gido un despliegue generalista y multifacético, y
tal vez por ello un tanto superficial, en deméri-
to de una adecuada especialización. No hay tal, a
lo que contribuye sin duda que el tratamiento de
los temas es depurado y sistemático, tanto en la
forma como en el fondo, y por consiguiente muy
eficaz. Enmarcado en la visión sistémica (mode-
los y niveles), que da forma al conjunto, los con-
tenidos se ordenan en el interior de las lecciones
en otro sistema implacable, en el que el cuerpo
de dichos contenidos viene siempre precedido de
una sección llamada ‘Propósito’ y seguido siem-
pre de los siguientes elementos o secciones: ‘Re-
sumen’, ‘Observaciones terminológicas’, ‘Notas
históricas’, ‘Orientaciones bibliográficas’, y ‘Ejer-
cicios’. Si la extensión del texto no lo evidenciara
suficientemente, estos últimos pueden dar fe del
grado de detalle en el desarrollo de los contenidos.
De añadidura, la condición de sistematicidad se
extiende a lo largo de todo el libro y también la de
sistemidad, como ponen de manifiesto las prolijas
referencias cruzadas entre lecciones, que lo con-
vierten en un objeto en el que todos (o casi todos)
los textos acaban reforzándose mutuamente, unas
Prólogo
veces por síntesis y otras por análisis, e integrán-
dose en una visión unificada.
Sobre ser didáctico, el libro tiene un carácter bá-
sico, que aquí no significa elemental o banal, sino
fundamental, vale decir desprovisto de accesorios.
Esto ya lo explica su autor en el prefacio, pero yo
quiero añadir que, siendo básico, es también denso
y duro, un auténtico curso universitario. Y progre-
sivo. Parte de un ordenador casi grotesco, por lo
sencillo, y va progresando sin pausa, desmenuzan-
do los mecanismos internos y funciones de máqui-
nas y sistemas, hasta llegar a las máquinas y siste-
mas más modernos y sofisticados. Te ves, qué sé
yo, estudiando hoy los entresijos de los modos de
direccionamiento, y al cabo de unos días o de unos
meses, según el ritmo, te encuentras con que te has
familiarizado con la memoria oculta, la memoria
virtual, la estructura MIMD, las arquitecturas de
comunicaciones, la comunicación entre procesos
en un sistema operativo, los sistemas operativos en
red, los lenguajes declarativos y un largo etcétera.
Uno de los valores del libro que más aprecio
personalmente es que es un libro culto, y esta cua-
lidad sí que es rara, palabra de honor. Me estoy
refiriendo más que nada a una cultura técnica, pe-
ro no sólo a la cultura específica que corresponde
a la materia que constituye el objeto de este libro
sino a una cultura técnica general. Ambas brotan
en cualquier pasaje del libro, aquí en un ejemplo,
allá en un ejercicio, aunque se concentran espe-
cialmente en las secciones históricas, terminoló-
gicas y bibliográficas, algunas de ellas antológi-
cas. Sus rasgos culturales y hasta eruditos, de la
más vieja raigambre universitaria europea, debe-
rían ser conceptuados por los profesores que elijan
este Curso para libro de texto como una oportuni-
dad para refinar sus paladares, incluido el hecho
espectacular de poder gozar de un estilo literario
sobrio, milimétrico, y al tiempo expresivo. Sepan
que en estas más de setecientas páginas se filtra
XV
una parte de los conocimientos y saberes de su au-
tor, el profesor Gregorio Fernández, que se extien-
den, además de al campo de la estructura y arqui-
tectura de los computadores, a los siguientes (y só-
lo cito los que yo he observado presencialmente):
Lógica, Inteligencia Artificial, Programación De-
clarativa e Imperativa, Bioingeniería, Técnicas de
Modelación y Simulación, Teoría de Autómatas, y
Cibernética y Teoría de Sistemas.
Y, para terminar con los calificativos al libro, di-
ré una obviedad: que es libro de un solo autor. En
efecto, es una obviedad, pero es asimismo una ra-
reza, porque ya es difícil encontrar un libro impor-
tante de texto sobre técnica moderna que no haya
sido escrito por dos o más autores. Y sin duda es
una enorme ventaja, por razones de calidad, ho-
mogeneidad y coherencia.
Vengo, por último, al autor. El dice que ha tra-
bajado en la elaboración de este libro más de seis
mil horas durante los últimos seis años. Soy testi-
go de ello. Ha elaborado el libro hasta en sus más
ínfimos detalles, lo que incluye toda la edición grá-
fica y de símbolos (le pido al lector que eche ahora
una ojeada rápida por sus páginas para que valore
lo que estoy diciendo). El libro que tenemos en las
manos está tal cual ha salido del despacho de Gre-
gorio. Y no es verdad que haya trabajado en él seis
mil horas. Según mis cuentas, han sido diecisiete
años, desde que empezamos juntos los que luego
fueron conocidos como «libros verdes de teleco».
El ha continuado y culminado la tarea con fuer-
za mental irrepetible y paciencia franciscana. Así,
su libro se convierte en una lección para todos los
que nos dedicamos a la tarea universitaria. Ya ha-
ce tiempo que Gregorio Fernández es un maestro
universitario, quiero decir un profesor de profeso-
res. Pero este libro es un instrumento que proyecta
su magisterio allí donde haya unos ojos para leer-
lo y una mente para estudiarlo, y un profesor para
aprender con él la tarea de enseñar.
XVI
Por eso decía al principio de mi prólogo que és-
te es un libro raro y magistral. Lo que quería ex-
presar es que es un libro con el que se ejerce un
magisterio. Y para aclarar del todo el concepto,
recurro, como antes hice, al Diccionario, reprodu-
ciendo tres acepciones de la voz ‘magistral’: Per-
teneciente o relativo al ejercicio del magisterio. 2.
Dícese de lo que se hace con maestría. 8. Aplícase
a instrumentos que por su perfección y exactitud
sirven de término de comparación para los ordina-
rios de su especie.
Prólogo
Pondré las cartas sobre la mesa. Con Gregorio
me unen una larga amistad y una colaboración de
muchos años, que tal vez me hayan hecho pasar
por alto algún defecto de su libro, que en todo caso
calificaría de menor comparado con su caudaloso
aliento y con la importancia de los rasgos que he
querido resaltar en este prólogo. Y le desafío al
lector a que me demuestre lo contrario.
Madrid, 1994
Fernando Sáez Vacas
Catedrático
Universidad Politécnica de Madrid

Este libro está concebido y escrito para:
• Servir como apoyo didáctico en un primer cur-
so sobre los fundamentos de la arquitectura de
ordenadores.
• Servir también como iniciación concreta1 al es-
tudio de los sistemas operativos, en un curso
sobre estos sistemas (que se supone precedido
de otro sobre fundamentos de arquitectura).
• Servir al lector que, de manera autónoma, desee
adquirir conocimientos básicos sobre la estruc-
tura y el funcionamiento de los ordenadores.
Lectores
Independientemente de la clasificación implíci-
ta en el párrafo anterior (alumno de un curso, o
«autónomo»), el libro se ha elaborado teniendo
presentes tres perfiles de lector2 :
1
«Iniciar [...] 3. fig. Instruir en cosas abstractas o muy
profundas». «Concretar[...] 3. Reducir a lo más esencial y
seguro la materia sobre la que se habla o escribe» (Dicciona-
rio de la Real Academia Española).
2
La primera edición, de 1994, era una refundición de tres
publicaciones dirigidas a distintos tipos de lectores: Fun-
damentos de los ordenadores, Servicio de Publicaciones de
la E.T.S.I. Telecomunicación, Madrid, 1991 (vol.1) y 1992
(vol.2), Iniciación concreta a los sistemas operativos, Servi-
cio de Publicaciones de la E.T.S.I. Telecomunicación, Ma-
drid, 1993, y Arquitectura de ordenadores (dos volúmenes),
Escuela de Organización Industrial, Madrid, 1993. En las edi-
ciones posteriores se ha ido depurando y actualizando el con-
tenido, pero siempre conservando el enfoque original.
XVII
Prefacio
• Estudiantes de ingeniería, con conocimientos
previos de programación en un lenguaje de alto
nivel y de circuitos lógicos.
• Profesionales en proceso de «reconversión» a
las tecnologías de la información y las comuni-
caciones.
• Profesionales o estudiantes de otras materias en
las que el ordenador se utiliza como una herra-
mienta cuya organización, estructura y funcio-
namiento internos es conveniente conocer para
obtener de ella el máximo provecho.
Como único requisito previo, se supone que el
lector tiene unos conocimientos mínimos de pro-
gramación. Para la mayor parte del Curso no es
necesario que sepa diseñar programas en ningún
lenguaje determinado, pero sí que sea capaz de
entender algoritmos sencillos escritos en un len-
guaje de alto nivel, preferiblemente en C, lenguaje
que se utiliza para presentar algunos algoritmos,
y también en algunos de los ejercicios propuestos.
Sólo para las dos últimas Lecciones, dedicadas a
la máquina virtual Java, es preciso tener cierta fa-
miliaridad con el lenguaje Java.
Algunas de las Lecciones requieren también
ciertas nociones de codificación y aritmética bina-
ria, así como de circuitos lógicos combinacionales
y secuenciales. Se incluyen sendos Apéndices con
todo lo hace falta saber sobre ambas cosas para la
comprensión del libro.
XVIII
Temática
El objeto de estudio aquí es el ordenador, no la
informática. Es decir, el instrumento, no la ciencia
construida a su alrededor.3
Ahora bien, los ordenadores pueden estudiarse
en diferentes niveles de abstracción (esto se ex-
plica en la «Lección 0»). Otras dos palabras del
título, «arquitectura» y «sistemas operativos»,
determinan los niveles en los que se centra este li-
bro: los que tienen que ver con el funcionamiento
interno del hardware y del software, sin descender
más que lo imprescindible a los circuitos.
Enfoque
También se ha querido dejar constancia en el tí-
tulo del enfoque adoptado. Veámoslo.
Se trata de un curso (y no tiene «Capítulos»,
sino «Lecciones»). Sea el lector un alumno «regu-
lar» o no, está escrito para que pueda seguirse «sin
ir a clase».4 Como consecuencia, se encontrarán
3
«La informática [computer science] es el estudio de los
fenómenos que rodean a los ordenadores [...] La máquina —
no ya el hardware, sino la máquina programada, viviente—
es el organismo que estudiamos». A. Newell y H. Simon:
«Computer science as empirical inquiry: symbols and sear-
ch». Comm. of the ACM, 19, 3 (Mar. 1976), pp. 113–126.
4
Si no fuera por la renuencia del autor a las «dedicato-
rias», habría dirigido la de este libro «a los alumnos que se
aburren en clase». Esto requiere una explicación (entre otras
cosas, para apaciguar el enojo de los colegas). Una de las abe-
rraciones de nuestro sistema educativo universitario es el acto
en que se ha convertido la «lección magistral» en la mayoría
de los centros. Entendemos que debería ser una clase de sínte-
sis y reforzamiento, impartida tras un período de estudio, ac-
ciones tutoriales, clases prácticas y evaluaciones parciales, y
preparada muy cuidadosamente. La limitación de recursos no
sólo hace inviable este proceso. Determina también un núme-
ro de alumnos por grupo (más del centenar en muchos casos)
que conduce a las «clases teóricas», monólogos en los que
el profesor, casi sin interacción con los alumnos (y agobia-
do a veces por «cubrir el programa»), expone, con su mejor
voluntad de hacerse entender, una sucesión más o menos or-
denada de conocimientos. Muy frecuentemente, preparando
estas clases, reflexiono sobre su escasa eficacia educativa. Y
me asombra la capacidad de los alumnos para cumplir estoi-
camente un «horario» que a veces incluye ¡seis horas segui-
das de clase! Salvo que uno fuese, además de profesor, un
Prefacio
más reiteraciones de las habituales. Pretendemos
asegurar la comprensión de cada concepto, asu-
miendo el riesgo de excedernos en el número de
palabras. No obstante, hemos buscado un término
medio, pues las Lecciones están muy interrelacio-
nadas y la reiteración tiene un límite. El lector en-
contrará con frecuencia referencias a «Apartados»
de otras Lecciones distintas a la que está estudian-
do (fácilmente localizables por la forma de enca-
bezar las páginas).
Y es un curso sobre conceptos básicos. Además
de complejos, los ordenadores son dependientes
de unas tecnologías que cambian muy rápidamen-
te. Un curso basado en los productos que hoy se
encuentran en el mercado tendría una utilidad efí-
mera, y los conocimientos transmitidos quedarían
rápidamente obsoletos. Afortunadamente, después
de más de sesenta años de sucesivas innovaciones,
pueden ya identificarse ciertos conceptos relativa-
mente invariantes e independientes de la tecnolo-
gía, y en ellos se centra el libro. Para concentrar-
se mejor en esos conceptos básicos, la exposición
se hace sobre «ordenadores ficticios» («Símplez»,
«Algorítmez» y «Regístrez»). Pero el «aislamien-
to» (o abstracción) total de la tecnología es impo-
sible. Ya sea para ilustrar conceptos o para motivar
al lector que conoce los ordenadores como usua-
rio, a lo largo del texto se dan algunos datos con-
cretos que ha sido preciso ir actualizando en las
sucesivas ediciones, y que seguramente empeza-
rán a quedar obsoletos al poco de publicarse esta
última.
Estructura
El curso está diseñado sobre la base de una vi-
sión sistémica de los ordenadores. En cada nivel de
abstracción se presentan diferentes tipos de des-
cripciones o modelos. En la «Lección 0» se explica
excepcional orador con poder de seducción del auditorio, ¿no
sería más rentable y gratificante para el alumno adquirir los
conocimientos por medio de la palabra escrita, a su ritmo y
manera? Ésta ha sido una de las motivaciones para escribir
este libro. Esperamos que nos sirva para organizar las clases
de un modo más sensato.
Prefacio
esta concepción sistémica, y a su término podre-
mos situar en ese contexto su estructura y conteni-
do. Adelantemos aquí que, aparte de esa Lección 0
y de tres Apéndices, consta de tres partes con ocho
Lecciones cada una.
Todas las Lecciones empiezan con un Aparta-
do de «Propósito». En él se fijan los objetivos de
la Lección y, cuando es la primera de una parte,
del conjunto de Lecciones. Se incluyen también
ahí las reflexiones o consideraciones previas que
sean necesarias como introducción. En los Apar-
tados de «Resumen» se recuerda lo tratado y en
su caso se añaden conclusiones finales. Nos ha pa-
recido conveniente ir complementando la exposi-
ción con algunos asuntos no estrictamente técni-
cos, que aparecen al final de las Lecciones: Con
los Apartados de «Observaciones terminológicas»
pretendemos compensar el abuso de barbarismos
tan extendido en la informática; para algunos tér-
minos hemos adoptado traducciones poco usua-
les, que se explican o se justifican en esos Aparta-
dos. En las «Notas históricas» presentamos algu-
nos hechos que creemos conveniente conocer para
la buena comprensión de los ordenadores.
Para su uso como «libro de texto», los concep-
tos incluidos en cada Lección pueden tratarse en
dos «clases» de unos cincuenta minutos, suponien-
do que se trata de clases de síntesis. Estimamos
que desarrollar el contenido de todas las Lecciones
requeriría una asignatura de unos quince créditos
(150 horas). Para una de seis créditos (módulo bas-
tante extendido en los planes de estudio actuales)
es preciso seleccionar. Al final de la Lección 0 se
dan algunas orientaciones a este respecto.
Materiales de apoyo
En las páginas web de la asignatura «Funda-
mentos de ordenadores» de la E.T.S.I. Telecomu-
nicación de la Universidad Politécnica de Madrid
(http://www.gsi.dit.upm.es/~gfer/ffoo/),
así como en las de «Arquitectura de ordenado-
res» (http://www.lab.dit.upm.es/~arqo/),
pueden encontrarse transparencias, problemas,
XIX
exámenes y dos simuladores, uno de Símplez
y el otro de Algorítmez. En otros Centros se
han desarrollado también simuladores de estas
máquinas, y algunos son públicamente accesibles:
• E.T.S.I.T. de Vigo (Universidad de Vigo):
http://www-gist.det.uvigo.es/esal/
• E.U.P. de Linares (Universidad de Jaén):
http://telecoslinares.iespana.es/
telecoslinares/programas.htm
• Facultad Regional de Mendoza (Universidad
Tecnológica Nacional, Argentina) :
http://web.frm.utn.edu.ar/tecnicad2/
tec_dig2/tools/te2simplez.html
Agradecimientos
Los conocimientos que trato de compartir aquí
los he adquirido en treinta años de actividad do-
cente e investigadora en la Escuela Técnica Su-
perior de Ingenieros de Telecomunicación de la
Universidad Politécnica de Madrid. No es posible
mencionar a todas las personas que, de un modo
u otro, han contribuido a mi formación y madura-
ción personal. Pero el riesgo de olvidar a muchos
no justificaría el dejar de distinguir a algunos.
Ante todos, Fernando Sáez Vacas. Él me inició
en la Informática y, sobre todo, en la forma abierta
de estudiar la tecnología, en la docencia univer-
sitaria, en la necesidad del rigor y la autocrítica.
Su amistad ininterrumpida ha sido y es una fuente
permanente de enriquecimiento.
Entre los profesores que han colaborado en la
impartición de la asignatura «Fundamentos de or-
denadores» (cuyo programa ha sido el germen del
libro), tengo que destacar, muy especialmente, a
Mercedes Garijo, que dedicó muchas horas a revi-
sar sucesivas versiones del texto y de las figuras, lo
que me ha permitido depurar inconsistencias, ca-
rencias, errores y erratas de todo tipo (huelga de-
cir que los que aún quedan son de mi exclusiva
responsabilidad). Pedro Alonso y Marifeli Sedano
han contribuido con un gran número de correc-
ciones. Las Lecciones de introducción a los sis-
XX
temas operativos (17 a 21) se mejoraron en las pri-
meras ediciones gracias a valiosas sugerencias de
Ángel Álvarez, Gonzalo León, Joaquín Seoane y
Juan Quemada. Algunos profesores de otros Cen-
tros me han hecho llegar también comentarios pro-
vechosos: Martín Llamas y Juan Carlos Burgui-
llo (Universidad de Vigo), Luis Sánchez y Alber-
to García (Universidad Carlos III), Joaquín López
(Universidad Alfonso X el Sabio), José R. Gon-
zález de Mendívil (Universidad Pública de Nava-
rra), Álvaro Suárez (Universidad de Las Palmas de
Gran Canaria), Francisco Rodríguez Rubio (Uni-
versidad de Sevilla), Iñaki Goirizelaia (Universi-
dad del País Vasco) y Sebastián García y Joaquín
Cañada (Universidad de Jaén).
Un antecedente de este libro fueron los dos vo-
lúmenes editados en la Escuela hace más de vein-
ticinco años. Eran el resultado de un trabajo de
coordinación de Fernando Sáez Vacas y mío en el
que los profesores con los que iniciamos el diseño
y la impartición de la asignatura contribuían con
varios capítulos: Pedro Alonso, Carmen Costilla,
Juan Quemada, Enrique Rivero y José María Ve-
la quizás reconozcan aquí todavía algunos detalles
inspirados en sus textos.
La actividad docente, cuando es fruto de una vo-
cación y no la obligación de un oficio, es placente-
ra y gratificadora, pero también exigente y ardua.
A potenciar los primeros atributos y mitigar los
efectos negativos de los últimos contribuye la inte-
gración en un entorno estimulante y enriquecedor
como el que he tenido la suerte de disfrutar. Ya he
mencionado a algunos compañeros, pero no pue-
do olvidar a otros que con los que colaboro o he
colaborado: Carlos Delgado, José Carlos Gonzá-
lez, José Miguel Goñi, Carlos Ángel Iglesias, Luis
Magdalena, Darío Maravall, Amalio Nieto, Encar-
na Pastor, Juan Riera, Juan Ramón Velasco, Angel
Viña...
Aunque difícil de precisar y cuantificar, es in-
negable y de obligado reconocimiento la positiva
influencia de los alumnos en la evolución profesio-
Prefacio
nal y personal de un profesor. Por su ahínco en la
detección de errores sobre las primeras ediciones,
y en la crítica constructiva, valga como represen-
tativo el de Óscar José Martínez de la Torre, que
en su momento fue delegado de los alumnos de la
Escuela, y actualmente, ya titulado, cursa el tercer
ciclo.
Iván Peña Rueda y Javier Rodríguez Dantart de-
sarrollaron, en el marco de sus proyectos fin de
carrera, los simuladores de Símplez y Algorítmez,
que permiten experimentar «virtualmente» con las
máquinas. En realidad son algo más que simulado-
res. Contienen herramientas para ensamblar mó-
dulos escritos en el lenguaje ensamblador, mon-
tarlos y cargarlos en la memoria. El de Símplez in-
cluye también una simulación de la ruta de datos
y del secuenciador para visualizar paso a paso la
ejecución de las instrucciones y la evolución tem-
poral de las microórdenes, así como un editor de
microprogramas. Si el lector los prueba apreciará
en pocos minutos la calidad de su diseño.
En los medios instrumentales, he hecho uso
de las aportaciones de Donald Knuth y de Les-
lie Lamport, creadores de TEX y LATEX, respecti-
vamente, así como de otras herramientas desarro-
lladas en la comunidad del software libre: Linux,
Emacs, Babel, Ispell, Idraw, Xfig...
Al publicarse la primera edición, en 1994, es-
timé que había dedicado a su elaboración más de
seis mil horas, casi cuatro mil de ellas en períodos
de vacaciones y fines de semana. Las sucesivas re-
visiones han supuesto un incremento importante
de esos números a lo largo de diez años. La deu-
da contraída con mi familia es tan grande que sólo
cabe dejar constancia de su existencia.
Madrid, noviembre de 2004
Gregorio Fernández

0.1. Propósito
Los ordenadores se pueden contemplar desde
distintos puntos de vista, dependiendo de la for-
mación y de la profesión del observador, de la ín-
dole de su relación con ellos e, incluso, de su in-
tención en un momento dado. En este libro, las in-
tenciones de los «observadores» (lector y autor)
parecen estar bien acotadas: no nos ocuparemos
de otras facetas que no sean estrictamente técni-
cas. Aun así, hay diversos puntos de vista. ¿Cuá-
les? Sorprendentemente (al fin y al cabo estamos
hablando de «simples máquinas»), una respuesta
(que no sea trivial) exige desarrollar antes cierto
marco conceptual. Y éste es el primer propósito.
Una vez obtenida la respuesta, será relativamente
fácil cumplir el propósito último (de esta Lección):
situar en ese marco los contenidos del libro.
Veremos que para describir a los ordenadores
hay varios tipos de modelos, y que tales mode-
los se construyen a partir de unos elementos que
se combinan siguiendo ciertas reglas. O, lo que es
igual, todo modelo se expresa en un lenguaje. En
las Lecciones siguientes estudiaremos esos mode-
los y esos lenguajes. Pero en ésta hablaremos de su
naturaleza, construyendo un metamodelo, y usan-
do la lengua española como metalenguaje. Pode-
mos decir que ésta es una «metalección».
1
Lección 0
Modelos y niveles
En consecuencia, esta (meta)lección tiene un
carácter más abstracto y generalista y un enfoque
menos técnico que el resto del curso. Su objetivo
es delimitar y enmarcar el contenido de éste, y, si
es posible, contribuir a sistematizar el estudio de
los ordenadores. Pero su lectura, aunque la con-
sidero muy recomendable (de lo contrario, habría
ahorrado estas cuarenta y cuatro páginas), no es
compulsiva ni necesaria para comprender las Lec-
ciones que le siguen. Si se omite, «sólo» se perderá
cierta perspectiva global. El lector poco aficiona-
do a visiones generalistas y más propenso a «ir al
grano» tiene la opción de leer el resumen del Apar-
tado 0.10 y pasar luego, sin más preámbulos, a la
Lección 1.
Sólo le pido, antes de que corra a hacerlo, que
termine de leer este párrafo (con la quizás vana es-
peranza de hacerle cambiar de idea). La idea de
abstracción tiene una connotación peyorativa para
muchas personas con pretendida vocación por la
ingeniería («esta explicación, este libro, esta asig-
natura, son demasiados abstractos...», «vayamos al
grano, concretemos...»). Sin embargo, le invito a
reflexionar seriamente sobre la siguiente proposi-
ción: sin abstracción no puede hacerse ingeniería;
todo lo más, artesanía.
2 Lección 0. Modelos y niveles
0.2. Sistemas y modelos
Un ordenador es un sistema complejo que pue-
de describirse mediante diferentes modelos en dis-
tintos niveles de una jerarquía de abstracciones1 .
Todo lo que sigue en esta Lección está dedicado a
explicar el significado de este escueto (y posible-
mente críptico para el lector) mensaje, y a extraer
consecuencias de él.
Sistemas
La acepción de «sistema» que aquí nos intere-
sa es la segunda del D.R.A.E.2 : «conjunto de co-
sas que relacionadas entre sí ordenadamente con-
tribuyen a determinado objeto». Entendiendo «co-
sa» en un sentido amplio3 , designa a un concep-
to generalizador que conduce, por una parte, a lo
que se ha llamado «pensamiento sistémico» (ne-
cesidad de enfoques globalizadores por contrapo-
sición a, o complementarios de, los reduccionistas
de las ciencias clásicas), y, por otra, a las «teo-
rías generales de sistemas» (o «teorías de siste-
mas generales»), construcciones abstractas (en sí
mismas, sistemas) que pretenden aplicarse a dis-
ciplinas muy diversas. Sin entrar en tales cuestio-
nes más de lo estrictamente necesario para nuestro
propósito, hemos de comentar algunos puntos que
consideramos importantes para la comprensión de
los sistemas llamados ordenadores.
1
Observe que este enunciado no es una definición de «or-
denador», sino la declaración de unas propiedades. Se utiliza
el verbo «ser» en el sentido de la predicación, no en el de
la identidad. (J. Ferrater y H. Leblanc: Lógica matemática.
Fondo de Cultura Económica, México, 1962). Parece ocioso,
a estas alturas, dar una definición de «ordenador».
2
Diccionario de la Real Academia Española, vigésimose-
gunda edición (2001), que citaremos con frecuencia.
3
O sea, pudiendo denotar tanto objetos físicos de nuestro
entorno material como objetos conceptuales elaborados por la
mente. Como dice Javier Aracil : «Se aplica [“cosa”] a todo
aquello que nos rodea ante lo que se puede preguntar signi-
ficativamente: ¿qué es eso? Se excluye únicamente aquello
ante lo que, siguiendo la sugerencia de los orteguianos, cabe
cuestionar: ¿quién es ese?» (J. Aracil: Máquinas, sistemas y
modelos. Un ensayo sobre sistémica. Tecnos, Madrid, 1986).
Los sistemas pueden ser materiales o concep-
tuales. Un ordenador, un automóvil, un edificio,
incluso un hombre (despojado éste último de cual-
quier connotación idealista o espiritual)4 , son sis-
temas materiales. Un manual de programación, un
esquema de las partes del automóvil y sus relacio-
nes, los planos del edificio, la fisiología, son siste-
mas conceptuales.
Estos ejemplos de sistemas conceptuales son
también sistemas abstraídos: cada uno de ellos
existe porque existe (o puede llegar a existir) un
sistema material que se corresponde con él, y cada
uno es un modelo (en el sentido que definiremos
más adelante) del correspondiente sistema mate-
rial (el manual es un modelo del ordenador, etc.).
Estos son los sistemas conceptuales que aquí nos
interesan, no otros, como las teorías matemáticas
o lingüísticas, que son sistemas abstractos cuya
existencia no está ligada a la de ningún sistema
material.
Los sistemas conceptuales son elaboraciones de
la mente humana. En ellos suele estar claro (o de-
bería estarlo) cuáles son las «cosas», o partes, que
los componen: en general, son símbolos (gráficos,
palabras, números). En los sistemas materiales no
está tan claro: en el límite, las partes serían las
«partículas elementales» de la Física. Sin embar-
go, nadie piensa así cuando fija su atención, por
ejemplo, en el sistema solar; más bien considerará
que las partes son el sol, los planetas y sus satéli-
tes, admitiendo que todos éstos son, a su vez, sis-
temas, o sea, subsistemas con relación al sistema
del que forman parte. En general, cuando estudia-
mos un sistema material lo consideramos formado
por subsistemas, también materiales, en cuya com-
posición no entramos; y, además, idealizamos ca-
da uno de estos subsistemas, es decir, nos queda-
mos con las características que consideramos rele-
4
Según el criterio de Aracil citado en la nota anterior, un
hombre no es una «cosa», pero sí podría ser un sistema com-
puesto por cosas. Por otra parte, cuando se estudian sistemas
de los que el hombre forma parte (sistemas sociales, sistemas
hombre–máquina, etc.) es obligado tomar el punto de vista
del hombre como «cosa».
0.2 Sistemas y modelos
vantes para nuestros fines y hacemos abstracción
de las que no lo son. Pero al actuar así lo que ha-
cemos es, realmente, construir un sistema concep-
tual, un modelo del sistema original.
Enseguida definiremos lo que es un modelo,
pero antes haremos unos breves comentarios so-
bre dos características de los sistemas: la apertura
y la complejidad.
Sistemas abiertos
Desde el mismo momento en que consideramos
un sistema estamos particionando el conjunto de
las «cosas» del universo en dos: las que forman el
sistema y todas las demás; estas últimas constitu-
yen el entorno del sistema considerado. Hay siste-
mas conceptuales (sistemas lingüísticos, sistemas
algebraicos, etc.) que son cerrados: se puede es-
tablecer una frontera impermeable entre el siste-
ma y el entorno. Pero todos los sistemas materiales
son, en mayor o menor medida, abiertos: hay par-
tes del sistema que interactúan con las del entorno
(es decir, que influyen sobre o que son influidas
por ellas). En general, un sistema abierto es aquél
que intercambia materia y/o energía y/o informa-
ción con su entorno. La Figura 0.1 (en la que los
círculos representan las partes o subsistemas, y las
flechas las influencias o interacciones) ilustra esta
definición.
Un ordenador es, desde luego, un sistema abier-
to: recibe datos y entrega resultados y, por tanto,
intercambia información con el entorno5 . Y, aun-
que a efectos meramente didácticos podemos estu-
diar su funcionamiento interno independientemen-
te de su función, su existencia sólo se justifica por-
que los beneficios que socialmente reporta este in-
tercambio son (supuestamente) más relevantes que
los costes que le acompañan.
5 6
También intercambia energía, pero los modelos que aquí
nos interesan hacen abstracción de este hecho. Observe que
el mismo concepto de «información» (Apéndice A) implica
una abstracción: la información ha de tener algún «soporte»
para ser almacenada y comunicada, y la grabación y la comu-
nicación sobre estos soportes implican algún tipo de energía.
3
sistema
entorno
Figura 0.1 Sistema abierto.
Esta definición de «sistema abierto» es clásica
en las teorías de sistemas generales. En el campo
de los ordenadores se utiliza de una forma mucho
más concreta y restrictiva. Lo veremos en el Apar-
tado 5.13.
Sistemas complejos
La complejidad es una propiedad que atribui-
mos, casi siempre de manera subjetiva6 , a ciertos
sistemas. Herbert Simon ha definido un sistema
complejo como «el compuesto por un gran nú-
mero de partes que actúan entre sí de manera no
sencilla»7 . La imprecisión de esta definición no es
ajena al hecho de que la complejidad no es un atri-
buto del sistema en sí: depende tanto del sistema
como del observador. Casi todos los sistemas en
los que centremos nuestra atención pueden pare-
cernos simples o complejos, dependiendo de que
dispongamos o no de descripciones suficientemen-
te buenas para responder a las preguntas, o resol-
ver los problemas que nos planteamos. De ahí que
haya una constante en la evolución del pensamien-
«La complejidad de un objeto está en los ojos del obser-
vador». G.J. Klir: «Complexity: some general observations».
System Research, 2, 2 (1985), pp. 131–140.
7
H.A. Simon: The Sciences of the Artificial. M.I.T. Press,
1973. Traducción de F. Gironella: Las ciencias de lo artificial.
A.T.E., Barcelona, 1978.
4 Lección 0. Modelos y niveles
to: la búsqueda de descripciones comprensibles de
sistemas que, en principio, parecen complejos (o
más complejos de lo que luego resultan ser cuan-
do se encuentra la descripción adecuada).
De los cuatro ejemplos de sistemas citados más
arriba, el ordenador, el automóvil, el edificio y el
hombre, seguramente muchos lectores considera-
rían en primera instancia como complejos sólo el
primero y el último, no los otros dos. Y es así por-
que disponen de descripciones comprensibles del
automóvil y del edificio que les permiten predecir
su función y/o su comportamiento para resolver
los problemas que se les plantean habitualmente,
y no así de los otros dos.
La invención de buenas descripciones (o buenos
modelos) es importante para comprender la reali-
dad (actividad del filósofo y del científico), para
actuar sobre ella (actividad de muchos otros pro-
fesionales: médicos, economistas, políticos...), pa-
ra concebir, construir o reparar artefactos (activi-
dad del ingeniero) y para movernos en una y utili-
zar adecuadamente los otros (actividad de todos).
Pero en todos los casos hay que ser precavidos, so
pena de resultar incautos. Desde el punto de vista
científico y filosófico, no se debe confundir la rea-
lidad con el modelo que, esclavos de nuestra per-
cepción, construimos8 . Y, desde el punto de vista
de la ingeniería, el diseño de artefactos apoyándo-
se en modelos lleva consigo el riesgo de creer que
el artefacto es el modelo, y sin embargo éste abs-
trae comportamientos que pueden ser importantes.
Esto es especialmente cierto en lo concerniente a
la integración del artefacto en el entorno social,
asunto frecuentemente olvidado en los planes de
estudio, y relacionado con lo que Mario Bunge lla-
ma «tecnopraxeología»9 .
Para un mismo sistema, el ordenador en nues-
8 otros que no se consideran relevantes para los fines
«No es que tu teoría sea tan amplia como la realidad; es
que tu percepción de la realidad es tan estrecha como tu teo-
ría». K. Craik: The Nature of Explanation. Cambridge Uni-
versity Press, Cambridge, 1943.
9
M. Bunge: Epistemología. Ariel, Barcelona, 1980: un li-
bro cuya lectura es muy recomendable para los estudiantes de
ciencias y de ingeniería.
tro caso, podemos utilizar descripciones distintas,
según cómo se contemple al sistema y según cuál
sea el fin de la descripción. Puesto que el sistema
se describe mediante un modelo, veamos qué en-
tendemos por «modelo» y qué tipos de modelos
podemos utilizar.
Modelos
Similarmente a lo que ocurre con el término
«sistema», «modelo» tiene varias acepciones. En
el campo de los ordenadores se habla, por ejem-
plo, del «modelo de von Neumann» o del «mode-
lo de Wilkes» para referirse a esquemas generales
que sirven de guía para el diseño de ordenadores, o
del «modelo tal de tal ordenador», aludiendo a un
sistema determinado del que se fabrican muchas
réplicas.
En la acepción que aquí nos interesa, un modelo
es, en sí mismo, un sistema, material o conceptual,
que se utiliza en lugar de otro10 al que, por su re-
lación con el modelo, podemos llamar original.
El modelado de un sistema consiste en buscar o
elaborar un modelo de ese sistema. Es un proce-
so intelectual pragmático y unidireccional (se uti-
liza un modelo en sustitución de un original) que
está presente en todo desarrollo teórico o aplica-
do, pero también en toda actividad humana (ac-
tuamos siempre suponiendo ciertas pautas o mo-
dos de comportamiento de las cosas y seres que
nos rodean).
Todo modelo es homomórfico (en el sentido
matemático de la palabra, no en el etimológico)
con el sistema original al que sustituye. Esto es,
la correspondencia entre ambos no es isomórfica o
biunívoca: el modelo sólo refleja los rasgos de in-
terés del original, haciendo abstracción de muchos
que se persiguen con la modelación (Figura 0.2).
10
«4. Esquema teórico, generalmente en forma matemáti-
ca, de un sistema o de una realidad compleja, como la evo-
lución económica de un país, que se elabora para facilitar su
comprensión y el estudio de su comportamiento». (D.R.A.E.)
0.2 Sistemas y modelos
sistema
(original)
homomorfismo
sistema
(modelo)
Figura 0.2 Sistema y modelo.
Aspectos semióticos de los modelos
La semiótica es una teoría lógica general de los
sistemas de símbolos. Siendo los lenguajes siste-
mas de símbolos, la semiótica ejerce la función
de un metalenguaje. Se distinguen tres niveles en
el estudio de los lenguajes, lo que da lugar a los
tres campos de la semiótica: la sintaxis se limi-
ta únicamente a los símbolos y a las leyes para su
combinación (reglas gramaticales); la semántica
se ocupa del significado de los símbolos, es decir,
de su relación con los objetos que designan; y la
pragmática trata de las relaciones de los símbo-
los y construcciones del lenguaje con las personas
que los utilizan. Así, y en el lenguaje natural, al
enunciar cosas como «“ordenador” es un sustan-
tivo» u «“ordenador” es también un adjetivo» nos
movemos en el campo de la sintaxis; al decir «un
ordenador es un artefacto pensado para liberar a
la mente humana de tareas rutinarias» u «“ordena-
dor” (sustantivo) es un vocablo de origen francés
que designa a ciertas máquinas también llamadas
computadores» estamos en el campo de la semán-
tica, y al afirmar que «hay quien ve un peligro en
los ordenadores» o «para la gran mayoría de sus
usuarios el ordenador es una magnífica herramien-
ta» pasamos al campo de la pragmática.
5
original
semántica
sintaxis modelo
pragmática
personas
Figura 0.3. Sintaxis, semántica y pragmática de los
modelos.
Los modelos son vehículos de comunicación, y,
por ende, lenguajes. Los modelos se construyen
siguiendo ciertas reglas para combinar elementos
(sintaxis), representan a un sistema original (se-
mántica) y sirven a un fin (pragmática). La Figu-
ra 0.3 ilustra estas relaciones entre el modelo, el
sistema que representa y las personas que lo usan.
Tipos de modelos
Las anteriores consideraciones nos sirven para
establecer un marco de clasificación de los mo-
delos siguiendo los tres niveles semióticos. Pero,
además, como sistemas que son, los modelos pue-
den ser materiales o conceptuales (abstraídos). De
acuerdo con esto, tenemos varios tipos de mode-
los, como resume la Figura 0.4 (en la página si-
guiente), que pasamos a comentar.
Por su sintaxis, los modelos materiales son tan
variados como los distintos tipos de elementos fí-
sicos que pueden componerlos (ladrillos, chips,
moléculas, células...) y las reglas para su combina-
ción; no hay clasificación posible de los modelos
materiales atendiendo a la sintaxis. En cuanto a los
6 Lección 0. Modelos y niveles

sintaxis semántica pragmática

icónicos comprensión
materiales
analógicos
uso
formalizados funcionales
conceptuales diseño/
(abstraídos) estructurales
no formalizados implementación
procesales

Figura 0.4 Clasificación de los modelos.

modelos conceptuales, estarán expresados en al-
gún lenguaje más o menos formalizado. La clasifi-
cación de la figura («formalizados» y «no forma-
lizados») en realidad representa los extremos de
una gama infinita de posibilidades (entre los mo-
delos puramente matemáticos expresados estricta-
mente, por ejemplo, en álgebra, y las descripcio-
nes totalmente literarias en lenguaje natural, nor-
malmente adoptamos una posición intermedia, sea
porque matizamos con el lenguaje natural el mo-
delo formal, sea porque procuramos restringir el
uso del lenguaje natural en las descripciones para
evitar ambigüedades).
Atendiendo a su semántica, los modelos mate-
riales pueden ser icónicos o analógicos. Los pri-
meros son los que se construyen con partes de la
misma naturaleza física que las partes del origi-
nal, de modo que el modelo reproduce al original
escala, se transforma la dimensión de altitud me-
diante el convenio de las líneas de nivel). Los mo-
delos analógicos son también materiales, y están,
por tanto, constituidos por objetos concretos, pero
de naturaleza diferente a la de las partes del origi-
nal. Es el caso de los «circuitos equivalentes» cuyo
comportamiento eléctrico es análogo al de algún
sistema mecánico original. La Figura 0.5 lo ilustra
con un ejemplo sencillo: el modelo matemático es
el mismo para los dos sistemas. Cada uno de ellos
es un modelo analógico del otro.
K
M
F(t)
D
2 x(t)
dx dx
M −−− + D −−− + Kx = F(t)
dt 2 dt 0

cambiando únicamente la escala de algunas mag- R L C

nitudes, y eventualmente abstrayendo, omitiendo
o transformando alguna magnitud. Es el caso de
las reproducciones a escala de vehículos para su i(t) = dq/dt
E(t)
estudio aerodinámico, o de los mapas topográfi-
+ −
cos. En este tipo de modelo aparece claramente la
propiedad de homomorfismo entre el modelo y el 2
dq dq
original (en la reproducción a escala de vehículos, L −−− + R −−− + q/C = E(t)
dt 2 dt
si sólo interesa el comportamiento aerodinámico
no se incluyen detalles de los subsistemas motor,
eléctrico, etc.; en los mapas, aparte del cambio de Figura 0.5 Un ejemplo de modelo analógico.
0.3 Función, estructura y proceso
Distinguiremos, desde el punto de vista semán-
tico, tres tipos de modelos conceptuales: funcio-
nales, estructurales y procesales. Ésta es la cla-
sificación más interesante a los efectos de este li-
bro. Dedicaremos los dos Apartados siguientes a
definir esos tipos y a ilustrarlos con ejemplos.
Finalmente, por su pragmática, los modelos
(sean materiales o abstraídos) pueden utilizarse,
entre otras cosas, para comprender al sistema ori-
ginal, para usarlo, para diseñarlo o para imple-
mentarlo. En cada caso se tendrá un punto de vis-
ta distinto sobre el sistema, y se utilizarán dife-
rentes modelos (materiales o conceptuales, más o
menos formalizados, funcionales, estructurales o
procesales). Trataremos de estos asuntos pragmá-
ticos en el Apartado 0.5.
0.3. Función, estructura y proceso
Modelos funcionales
Los modelos funcionales describen la función
del sistema: sus acciones sobre el entorno y sus
reacciones a éste11 . De todas las interacciones po-
sibles entre el sistema y el entorno se seleccionan
algunas para el modelo y se clasifican en estímu-
los (influencias del entorno sobre el sistema) y res-
puestas (influencias del sistema sobre el entorno).
Como ilustra la Figura 0.6, el modelo del sistema
es una caja negra12 que recibe estímulos (o «en-
tradas») y genera respuestas (o «salidas»). La res-
puesta ante un determinado estímulo (o sucesión
de estímulos) es el comportamiento del sistema
para ese estímulo.
Un modelo funcional de un sistema es una des-
cripción de todos sus comportamientos13 . Es decir,
una descripción de todos los posibles estímulos y
11
«Función: Capacidad de actuar propia de los seres vi-
vos y de sus órganos, y de las máquinas o instrumentos»
(D.R.A.E.)
12
Esta es una denominación establecida, aunque «caja opa-
ca» se ajustaría más a la idea.
13
No se olvide que «funcional» se refiere a «función», no a
«funcionamiento». El funcionamiento (actividad interna) de
un sistema se describe mediante un modelo procesal.
7
todas las posibles respuestas del sistema, y de có-
mo unos se relacionan con las otras en cada ins-
tante. Así son los modelos de ordenador definidos
en los manuales de programación, el modelo de
comportamiento del automóvil que enseñan en las
«autoescuelas», o los «modelos del hombre» de la
psicología conductista.
Al establecer un modelo funcional se seleccio-
na un número finito de tipos de estímulos y de res-
puestas (lo que se traduce, al formalizar el modelo,
en un número finito de variables de entrada y de
salida), y esto ya significa una cierta abstracción,
puesto que las relaciones del sistema con el en-
torno pueden ser innumerables. Por otra parte, he-
mos dicho que un modelo funcional debe describir
todos los estímulos, las respuestas y las relaciones
entre unos y otras. Frecuentemente, la enumera-
ción exhaustiva (es decir, para todos los valores
posibles de las variables de entrada y salida selec-
cionadas) es imposible, y se utiliza o bien un mo-
delo funcional incompleto (es el caso del «mode-
lo de autoescuela», que incluye el comportamiento
dinámico habitual, pero excluye habilidades domi-
nadas sólo por especialistas) o bien una descrip-
ción intensional, no extensional14 (es el caso de
los modelos de sistemas dinámicos lineales, en los
que se utilizan ecuaciones diferenciales como las
de la Figura 0.5, o «funciones de transferencia»,
que engloban en una sola fórmula las infinitas re-
laciones posibles entre las entradas y las salidas).
estímulos sistema respuestas
modelo = {comportamientos} = {respuesta = f(estímulos)}
Figura 0.6 Modelo funcional («caja negra»).
14
Utilizamos estos adjetivos (no admitidos en el D.R.A.E.)
con su sentido matemático: un conjunto puede definirse «por
extensión» o «por intensión».
8 Lección 0. Modelos y niveles
Modelos estructurales
Los modelos estructurales describen la organi-
zación del sistema como conjunto de partes inter-
relacionadas. En la mayoría de las definiciones de
«sistema» (como la reproducida más arriba) sub-
yace una concepción estructural. Un modelo es-
tructural comprende a los componentes del siste-
ma (subsistemas), definidos de manera funcional,
y a las relaciones entre estos componentes (Figu-
ra 0.7). Ambas cosas, si están completamente es-
pecificadas, determinan (al menos, teóricamente)
la función del sistema. Modelos estructurales que
determinan los modelos funcionales de los tres sis-
temas citados más arriba son: componentes bási-
cos (memorias, registros, etc.), con sus conexio-
nes y leyes de interacción para el ordenador, partes
mecánicas y leyes de la mecánica para el automó-
vil, y conceptos y leyes de la psicología cognosci-
tiva para el hombre.
Ahora bien, siendo los modelos representacio-
nes aproximadas de los sistemas, la «determina-
ción» del modelo funcional a partir del estructu-
ral es siempre relativa. Así, los modelos de la psi-
cología cognoscitiva son (al menos de momento)
demasiado burdos para poder deducir de ellos las
leyes de la psicología conductista. Y aun si los
modelos funcionales de los componentes son su-
ficientemente precisos, en la práctica el proceso
deductivo puede ser inabordable (como deducir el
comportamiento de una persona a partir de un per-
fecto conocimiento de la bioquímica). Por eso he-
mos matizado más arriba que el modelo estruc-
tural determina teóricamente al funcional. Y por
eso, para el estudio de sistemas complejos se in-
troducen modelos en distintos niveles de abstrac-
ción. Elevar el nivel de abstracción permite elabo-
rar modelos útiles para sistemas complejos pero
sacrificando la posibilidad de que los modelos en
un nivel alto puedan estar completamente deter-
minados por los de un nivel más bajo. En general,
esta indeterminación justifica el aforismo aristoté-
lico «el todo es más que la suma de sus partes»,
que en los sistemas se traduce por la aparición de
sistema
estímulos respuestas
modelo = {modelos funcionales subsistemas}
+ {interrelaciones}
Figura 0.7 Modelo estructural («caja transparente»).
propiedades emergentes: las que resultan como
consecuencia de interacciones entre las partes y no
pueden deducirse mediante análisis del modelo es-
tructural15 .
Uno podría esperar que las cosas fuesen más fa-
vorables en un sistema más «determinado» como
es el ordenador, y que el perfecto conocimiento
de sus componentes e interacciones nos permitie-
se predecir todos sus posibles comportamientos.
O, dicho en términos más prácticos, que dado un
programa y unos datos, pudiésemos inferir, con to-
da certeza, cuáles van a ser los resultados. Pero
no es así. El ordenador no es tan complejo como
muchos sistemas vivos, pero sí lo suficiente como
para que sus descripciones tengan que hacerse en
distintos niveles de abstracción, y lo dicho en el
párrafo anterior le es también aplicable. Volvere-
mos sobre los niveles en el Apartado 0.7, pero se-
ñalemos aquí la trascendencia de este hecho. En
efecto, por una parte es el desencadenante de toda
una problemática en la ingeniería del software: la
de tratar de conseguir que los programas funcio-
nen correctamente16 . Por otra, es posible diseñar
15
Ésta es una reformulación en términos de modelos del
concepto de «emergencia» propuesto por George Henry
Lewes (Problems of Life and Mind, vol. 2. Kegan Paul, Tren-
ch, Turbner, and Co., Londres, 1875), pero ya enunciado (con
el nombre de «efectos heteropáticos») nada menos que por
John Stuart Mill (System of Logic. Longmans, Green, Rea-
der, and Dyer, Londres 1843).
16
«Todo programa real contiene errores mientras no se de-
muestra lo contrario, lo cual es imposible» (T. Gilb: «Laws of
unreliability». Datamation, 21, 3, Mar. 1975). Sólo reciente-
mente se han empezado a desarrollar modelos que permiten,
en ciertos casos, garantizar que un programa construido con
esos modelos es correcto (véase el Apartado 22.2).
0.3 Función, estructura y proceso 9

programas que exhiban comportamientos impre-
visibles o «emergentes»; el aprendizaje en el or-
denador se consigue si esos comportamientos van
«mejorando» en algún sentido.
Sigamos con los modelos estructurales y con un
ejemplo que nos permitirá insistir en esta posibi-
lidad de aprendizaje en los ordenadores. Es fre-
cuente que un mismo sistema, con un determinado
modelo funcional, pueda representarse por distin-
tos modelos estructurales. Dicho de otro modo, el
modelador, dependiendo de su punto de vista o de
su intención (pragmática) puede adoptar distintas
descomposiciones.
binaria del resultado a decimal y presenta este re-
sultado decimal por la pantalla. Una posible des-
composición es la de la Figura 0.8(c), en la que se
han agrupado las operaciones de lectura, escritura
y transformaciones de representación en un «pro-
grama principal», y la del cálculo del factorial en
una «función». Este modelo hace abstracción del
hardware en el que se ejecutan las operaciones.
ratón pantalla
teclado

Fijémosnos, por ejemplo, en el sistema familiar

de un ordenador personal con pantalla gráfica, te- placa base controlador
serial
controlador
de video
clado y ratón (nos olvidaremos, para simplificar,
de discos y otros componentes). Este ya es un mo- bus
delo estructural, suficiente para muchos usuarios
y vendedores de ordenadores. Pero si uno no se
fuente de
conforma con considerar la «caja» como una «ca- alimentación

ja negra», y abre la carcasa, con unos mínimos

(a) componentes físicos
conocimientos puede identificar fácilmente cuatro
grandes componentes: la fuente de alimentación,
la «placa base» (que incluye los circuitos de la
unidad central de procesamiento y de la memo- entrada UCP salida

ria principal), la placa controladora de vídeo y una

placa más pequeña con unos circuitos para contro-
lar al ratón (los del teclado suelen estar incluidos MP

en la placa madre, y, a veces, también los del ra-

tón). Uno puede rápidamente establecer el modelo (b) componentes conceptuales

de la Figura 0.8(a). O bien puede decidir que no

le interesa lo que se refiere al suministro de ener-
gía ni a la disposición física, y, haciendo abstrac- dato programa resultado
principal
ción de tales cosas, agrupar los componentes de
más bajo nivel (los circuitos) por su función. Lle-
gará así al modelo «clásico» que muestra la Fi-
función
gura 0.8(b). Pero cabe también que no le interesen
en absoluto estas descomposiciones en componen-
(c) componentes abstractos
tes físicos, sino otra que sea de más utilidad para para un programa
describir lo que ocurre en la ejecución de un deter-
minado programa. Sea éste uno que lee del teclado
un número natural, lo convierte a la representación Figura 0.8. Descomposiciones estructurales de un or-
binaria interna, utiliza una función para calcular el denador.
factorial del dato leído, convierte la representación
10
¿Puede aprender un ordenador?
«Estructura» y «función» suelen aparecer cla-
ramente diferenciadas en los sistemas artificiales,
pero no en los seres vivos (y lo mismo ocurre en-
tre «función» y «proceso»)17 . Esto es así porque
los seres vivos (y los sistemas sociales) cambian
estructuralmente con el tiempo, lo que les permite
adaptarse y aprender. Pero también las máquinas
pueden estar dotadas de esa capacidad. Algunas,
por su propia concepción: los autómatas celulares
y las redes neuronales. Otras, como el ordenador,
por la versatilidad que se deriva del hecho de ser
programable.
Volvamos a los modelos estructurales de la Fi-
gura 0.8. En el primero no tiene sentido pensar
en modificaciones estructurales: las «placas» se
conectan en una configuración fija y ni ellas ni sus
partes cambian. Lo mismo puede decirse, en prin-
cipio, en el segundo modelo estructural, aunque
cabe señalar que se han propuesto algunos mode-
los adaptables para la unidad central de procesa-
miento (véase nota a pie de página en el Aparta-
do 4.9). Consideremos, sin embargo, el modelo de
la Figura 0.8(c). Más arriba hemos concretado di-
ciendo que el «programa principal» lee un dato,
escribe un resultado y realiza algunas transforma-
ciones, mientras que la «función» calcula el facto-
rial. Pero el mismo modelo es aplicable de manera
más general. Analicemos otra situación.
Supongamos que el «programa principal» reci-
be como datos una secuencia de letras que for-
man una frase en español y entrega como resul-
tados una secuencia de sonidos por un altavoz, y
que la «función» modifica la estructura del pro-
17
«La antítesis entre estructura y función, morfología y
fisiología está basada en una concepción estática del orga-
nismo. En una máquina hay una disposición fija que puede
ponerse en movimiento, pero también puede permanecer en
reposo [...] Realmente, esta separación entre una estructura
preestablecida y los procesos que ocurren en la estructura no
se aplica al organismo vivo [...] Las llamadas estructuras son
procesos lentos de larga duración, y las funciones son proce-
sos rápidos de corta duración». (L. von Bertalanffy: Problems
of Life: An Evaluation of Modern Biological and Scientific
Thought. Watts, Londres, 1952).
Lección 0. Modelos y niveles
grama dependiendo del parecido que hay entre es-
tos sonidos y la pronunciación correcta de la fra-
se (pronunciación que se le da, al mismo tiempo
que se da la frase al programa, por otro dispositivo
de entrada). Si se consigue que a medida que se
van sucediendo estímulos y respuestas vaya me-
jorando ese parecido hasta que, finalmente, el sis-
tema «lea» bien frases que nunca antes había oí-
do ¿no podemos decir que la máquina (formada
por el ordenador y el programa) «ha aprendido
a leer»? (aunque, desde luego, no haya llegado a
«comprender»). No se trata de ninguna utopía: se
han diseñado sistemas con ese modo de comporta-
miento18 .
El asunto del aprendizaje en ordenadores no só-
lo es intelectualmente muy atractivo, tiene tam-
bién importantes aplicaciones en ingeniería, como
el control de sistemas complejos (donde un mo-
delo del sistema a controlar es impracticable, y el
sistema de aprendizaje se va adaptando para con-
seguir los objetivos), la enseñanza individualizada
por ordenador (donde el sistema aprende un mode-
lo del alumno concreto), la minería de datos (des-
cubrimiento de conocimientos en bases de datos),
la minería de la web (descubrimiento de relacio-
nes estructurales entre páginas, o de patrones de
uso a partir de los ficheros en los que se registran
las visitas), etc. Pero está fuera del alcance de este
libro, y no lo volveremos a tratar, salvo por algu-
nas alusiones, en los Apartados 1.7 y 15.219 .
18
Por ejemplo, para la lengua inglesa, y con muchas limi-
taciones, «NetTalk», basado en la programación de una red
neuronal. (T.J. Sejnowski y C.R. Rosemberg: NetTalk: a pa-
rallel network that learns to read aloud. Technical Report
TR-86-01, Dep. Electrical Eng., John Hopkins Univ., 1986).
Durante los últimos años se ha ido progresando lentamente
en este difícil campo de aplicación de las redes neuronales al
reconocimiento del lenguaje hablado; véase, por ejemplo, el
artículo de N. Morgan y H.A. Bourlard: Neural networks for
statistical recognition of continuous speech, Proc. IEEE, 83,
5 (May 1995), pp. 742–770.
19
Recomendamos al lector interesado el libro de Tom Mit-
chell: Machine Learning, McGraw-Hill, 1997.
0.3 Función, estructura y proceso
Modelos procesales
Así como un modelo funcional describe la fun-
ción dinámica externa (relaciones entre sistema y
entorno) y un modelo estructural describe la orga-
nización estática interna (partes e interacciones),
un modelo procesal describe la actividad dinámi-
ca interna o proceso de un sistema material. En
efecto, si el sistema exhibe un comportamiento di-
námico en sus relaciones con el entorno, necesa-
riamente tienen que producirse cambios en su in-
terior. Un modelo procesal describe estos cambios,
haciendo abstracción de la estructura, basándose
en las ideas de estados y transiciones.
El estado es una entidad abstracta, conceptual,
que podemos definir como la información mínima
necesaria en un instante dado para, conociendo la
evolución de los estímulos a partir de ese instante,
predecir la evolución de las respuestas. El estado
resume la «historia» del sistema. Ante un estímulo
en un instante, el estado cambia, y a este cambio
de un estado al siguiente se le llama transición20 .
Un proceso es una sucesión de estados y transi-
ciones (y de respuestas asociadas a ellos). Su des-
cripción formal se hace mediante dos funciones
matemáticas: la función de transición determina
el estado siguiente, dependiendo del estado actual
y del estímulo que se reciba, y la función de sali-
da determina la respuesta para el estado actual y el
estímulo recibido (Figura 0.9). A partir del estado
en un determinado instante y de los estímulos que
desde ese instante se vayan recibiendo, el mode-
lo procesal determinará el proceso que seguirá el
sistema, es decir, la secuencia de estados, de res-
puestas y de transiciones entre estados.
Un modelo procesal es un sistema conceptual,
y como tal no tiene sentido decir que esté en un
20
En la Segunda Parte veremos que en los modelos de des-
cripción del hardware los estados se suceden sin que parezca
existir ningún estímulo. Esto es así cuando el sistema está
«sincronizado», de modo que regularmente cambia de un es-
tado al siguiente. Pero, en realidad, siempre hay un estímulo:
el paso inexorable del tiempo. En los ordenadores y en otros
sistemas digitales este estímulo tiene, además, una materiali-
zación bien clara: la señal periódica del reloj.
11
función de
transición
estímulos estado estado respuestas
i i+1
función de
salida
modelo = {función de transición, función de salida}
Figura 0.9 Modelo procesal («caja abstracta»).
estado u otro21 . Un proceso, por el contrario, es
un sistema material (las actividades internas son
reales, aunque se abstraigan en el modelo), y como
tal en cada momento estará en un estado.
Un modelo procesal incluye el conjunto de es-
tados, Q, el de estímulos o entradas, E, y el de
respuestas o salidas, S, y las funciones de tran-
sición, f , y de salida, g. Si los conjuntos son fi-
nitos (Q = {q0 , q1 , ..., qn }, E = {e0 , e1 , ..., em },
S = {s0 , s1 , ..., sr }) las funciones de transición
y de salida son discretas: qt+1 = f (et , qt ) y
st+1 = g(et , qt ), donde «t» se refiere al «instante
actual» y «t + 1» al «instante siguiente».
Decíamos que los modelos procesales son abs-
tractos. Quizás a algún lector se lo parezcan dema-
siado. Para ayudarle, pondremos algunos ejemplos
en el siguiente Apartado. Terminamos éste con una
consideración similar a la que hacíamos más arriba
con respecto a los «sistemas abiertos»: el concep-
to de proceso, aquí definido de manera general, se
utiliza en el campo de los ordenadores con un sig-
nificado mucho más concreto, como veremos en el
Apartado 17.9.
21
«Los objetos concretos o materiales son y están: existen
físicamente y están en algún estado. Los objetos conceptua-
les, en cambio, son: existen (conceptualmente), tienen pro-
piedades conceptuales que no posee objeto concreto alguno,
tales como la propiedad de ser un conjunto, o una relación, o
un espacio. Los conjuntos no se mueven, las funciones no me-
tabolizan, los espacios no procrean, las estructuras algebrai-
cas no pasan hambre, las derivadas no explotan.» M. Bunge:
Epistemología. Ariel, Barcelona, 1980.
12 Lección 0. Modelos y niveles

0.4. Ejemplos de sistemas y modelos x(t)

x
Los ejemplos que siguen se refieren a sistemas 0
de distinta naturaleza. El lector puede encontrar,
dependiendo de sus conocimientos previos, mayor
o menor dificultad para entenderlos, pero espera-
mos que, en su conjunto, estas ilustraciones sirvan t
para que capte las diferencias entre modelos fun-
cionales, estructurales y procesales.

Ejemplo 1: un sistema mecánico

Volvamos a la Figura 0.5, introducida para ilus-
trar que un sistema eléctrico es un modelo analógi-
co de un sistema mecánico22 . Las ecuaciones son
modelos funcionales de los correspondientes siste-
mas. En efecto, en el sistema mecánico podemos
considerar que la «entrada» o «estímulo» (acción
del entorno sobre el sistema) en cada momento es
la fuerza aplicada, F (t), y que la «salida» o «res-
puesta» es el desplazamiento de un punto del siste-
ma, x(t), con respecto a la posición de reposo. La
ecuación resume todas las relaciones posibles en-
tre la entrada y la salida. Así, si como consecuen-
cia de una fuerza aplicada en el instante t = t0 el
desplazamiento es x0 > 0 y si a partir de ese mo-
mento no se aplica ninguna fuerza (F (t) = 0 para
t > t0 ), la evolución de la salida, x(t), se pue-
de obtener matemáticamente integrando la ecua-
ción; el resultado, puesto en forma gráfica, es el
que muestra la Figura 0.10: un movimiento oscila-
torio amortiguado.
Para el modelo estructural consideramos que el
sistema está formado por tres partes: una masa,
un amortiguador y un resorte. Suponemos que el
amortiguador y el resorte carecen de masa, que
la masa y el amortiguador carecen de propiedades
elásticas, etc. La fuerza total aplicada se reparte
entre las tres partes:
F (t) = Fm (t) + Fa (t) + Fr (t)
22
También el sistema mecánico es un modelo analógico del
eléctrico. Pero lo normal, por razones prácticas (facilidad de
manipulaciones y medidas), es que se utilice el segundo como
modelo del primero.
Figura 0.10. Un modo de comportamiento del sistema
mecánico de la Figura 0.5.
y el comportamiento (modelo funcional) de cada
parte viene dado por leyes de la Física:
d2 x
Fm (t) = M · dt2
para la masa,
dx
Fa (t) = D · para el amortiguador, y
dt
Fr (t) = K · x para el resorte.
El modelo estructural, al definir por completo la
interrelación entre partes y el modelo funcional de
cada parte, determina totalmente el modelo fun-
cional del sistema. De hecho, lo que ocurre es que
el modelo funcional procede de las simplificacio-
nes hechas en el modelo estructural.
Para establecer un modelo procesal hemos de
definir las variables de estado. De acuerdo con la
definición de «estado» dada anteriormente, estas
variables deben ser tales que baste con conocer sus
valores en un instante t = t0 y los valores de F (t)
desde t = t0 hasta t > t0 para poder calcular x(t)
en t > t0 . Pueden servir como variables de estado
x(t) y v(t) = dx(t)
dt : desde un punto de vista mate-
mático, para integrar la ecuación que aparece en la
Figura 0.5 (y poder así calcular x(t)) hacen falta
dos condiciones iniciales: x(t0 ) y x0 (t0 ); desde un
punto de vista intuitivo, basta conocer la posición
y la velocidad con que se mueve el sistema en un
momento para saber dónde va a estar después. El
modelo procesal viene dado por las ecuaciones de
estado:
0.4 Ejemplos de sistemas y modelos
dx/dt
x sas depende, por una parte, del número de pre-
0 x
Figura 0.11. Trayectoria correspondiente al comporta-
miento de la Figura 0.10.
dx(t)
= v(t)
dt
dv(t) K D 1
dt = −M · x(t) − M · v(t) + M · F (t)
que determinan, de forma continua, el cambio de
un estado (x(t), v(t)) al siguiente. El espacio de
estados es el conjunto de valores posibles del par
(x(t), v(t)): todo el plano real. A partir de un es-
tado inicial, y para un estímulo F (t), la sucesión
de estados (puntos en el plano) forma una tra-
yectoria. En la Figura 0.11 puede verse la tra-
yectoria correspondiente al caso de la Figura 0.10
(x(t0 ) > 0, v(t0 ) = 0 y F (t) = 0 para t > t0 ).
Ejemplo 2: un sistema ecológico
Imaginemos dos especies animales. Los anima-
les de una especie son presas, y los de la otra, pre-
dadores. Nos interesa un modelo de la evolución
en el tiempo de la población de cada una de las
especies. Hagamos las siguientes hipótesis:
1. Las variables P (t) y D(t) representarán a los
números de presas y de predadores (o depre-
dadores) existentes en el instante t. Sus valores
son números naturales, pero nuestro modelo las
tratará como variables continuas (con valores
reales).
2. Las presas se reproducen sin limitación; si no
hubiese predadores su crecimiento sería expo-
nencial.
3. Los predadores viven y se reproducen si hay
13
suficientes presas; si no hubiese presas, su nú-
mero tendería asintóticamente a cero.
4. La tasa de crecimiento de la población de pre-
sas (cuanto más hay, más crece), y, por otra, del
número de encuentros, que es proporcional al
producto P (t) · D(t) (cuanto más hay menos
crece la población).
5. La tasa de crecimiento de la población de pre-
dadores depende igualmente del número de
predadores (cuanto más hay, menos crece, por-
que tienen que repartirse a las presas), y del nú-
mero de encuentros (cuanto más hay, más cre-
ce).
6. Abstraemos cualquier interacción con el en-
torno.
Teniendo en cuenta las hipótesis 4 y 5 es fácil
expresar gráficamente las relaciones entre las va-
riables como indica la Figura 0.12. Este tipo de
modelo estructural se llama diagrama causal.
Y, combinando todas las hipótesis, tampoco es
difícil cuantificar las relaciones en forma de ecua-
ciones diferenciales:
dP
dt = K11 · P − K12 · P · D
dD
dt = −K22 · D + K21 · P · D
Estas son las conocidas ecuaciones de Volterra,
y son un modelo procesal de nuestro sistema.
¿Y el modelo funcional? Pues bien, la última hi-
pótesis equivale a decir que estamos considerando
un sistema cerrado. Por tanto, no existe modelo
funcional.
+
+ P D −
−
Figura 0.12. Modelo estructural (diagrama causal) de
las presas y los predadores.
14 Lección 0. Modelos y niveles

Ejemplo 3: un sumador binario

E
1
Los dos ejemplos anteriores se refieren a siste- ... e12 e11 e10 sumador S
E ... s2 s1 s0
mas continuos: las magnitudes de interés toman 2
serial
... e22 e12 e02
valores en una escala de números reales. Por ese
motivo, los modelos están expresados en el tipo de ... t2 t1 t0 ... t2 t1 t0
ecuaciones matemáticas que permiten trabajar con
variables de esta naturaleza. Analizaremos ahora S= E + E
1 2
un sistema que es discreto, en el sentido de que las
magnitudes sólo pueden tomar, en cada momento, Figura 0.13. Sumador binario serial: modelo funcio-
uno de entre un conjunto finito de valores, y ade- nal.
más los cambios de esos valores no ocurren con- −
O tiempo
tinuamente a lo largo del tiempo, sino solamente
en instantes determinados. Se trata de un sistema R

electrónico digital sencillo: un sumador binario se- e

1
rial.
En primer lugar, veamos su descripción funcio- e
2
nal. Un sumador binario es un sistema que suma
dos números expresados en el sistema de numera- z
ción de base 2 y da el resultado en el mismo siste-
s
ma23 . En los ordenadores es un componente de la
unidad aritmética y lógica que funciona en para- q
lelo, es decir, los bits (dígitos binarios) que cons-
tituyen los sumandos se presentan todos al mismo
tiempo (es un circuito combinacional24 ), pero aquí Figura 0.14. Sumador binario serial: ejemplo de com-
consideramos el caso de un sumador serial, en el portamiento.
que los bits de los sumandos se presentan secuen-
cialmente y por parejas, y los bits del resultado se
dad, el comportamiento está definido por los valo-
obtienen también secuencialmente. Es decir, pri-
res de la entrada y la salida, pero la figura incluye
mero se presentan los dos bits de menor peso, el
más información: la variable interna z representa
sumador los suma y entrega el bit de menor peso
al acarreo; q (también interna) es el «acarreo retar-
del resultado (y toma nota del acarreo, si lo hay,
dado», o acarreo de la suma binaria en el instante
pero esto es una actividad interna), luego los si-
t − Θ, que ha de sumarse con et1 y et2 en el instante
guientes, etc.
t. R es la «señal de reloj», que marca el período,
La Figura 0.13 presenta al sistema como una ca- Θ, de presentación de los estímulos. Las variables
ja negra, y en la Figura 0.14 puede verse un ejem- q y z representan cosas que «pasan dentro», y por
plo de comportamiento que corresponde al caso tanto no forman parte del modelo funcional. Pero
particular 011001+011101 = 11011025 . En reali- el período Θ sí es un parámetro funcional impor-
23
En el Apéndice A se resume la aritmética con base 2, o tante, ya que es preciso conocerlo para poder usar
binaria, en la que sólo hay dos dígitos, 0 y 1. el sistema.
24
En el Apéndice B se resumen los principios de los cir- Por tanto, el modelo funcional (que incluye a
cuitos lógicos combinacionales y secuenciales.
25
Para interpretar bien la Figura 0.14, obsérvese que los
todos los comportamientos particulares posibles)
dígitos binarios están representados en ella en sentido inverso puede expresarse formalmente de una manera muy
a como los escribimos sobre el papel. sencilla:
0.4 Ejemplos de sistemas y modelos
(a) La relación entre las entradas y las salidas es
S = E1 + E2 , donde S, E1 y E2 represen-
tan, de manera general, números expresados
en binario (cadenas de bits).
(b) Los bits que forman las cadenas de entrada
deben presentarse con un período Θ.
Un posible modelo estructural del sumador
puede establecerse con dos componentes, una
«etapa de sumador» y un «circuito de retardo»,
conectados como indica la Figura 0.15. Para que
el modelo estructural esté completo (de modo que
el modelo funcional quede totalmente determina-
do a partir de él) hay que dar modelos funcionales
de ambos componentes. Si e1 , e2 , s, z y q repre-
sentan dígitos binarios, estos modelos son:
Para la etapa de sumador:
s = (e1 + e2 + q)(mód 2)
 te, predecir la evolución de las respuestas». En es-
 0
si e1 + e2 + q = 0

 te caso, la única información necesaria para poder
 o si e1 + e2 + q = 1
z=
 1 si e1 + e2 + q = 10

 sentan dos valores particulares en las entradas es

o si e1 + e2 + q = 11
Es decir, s es el bit menos significativo de la su-
ma binaria de los dos bits que se presentan en un
momento dado a la entrada, junto con el posible
acarreo (q) de la suma anterior, y z es el acarreo
generado que ha de guardarse para la suma de los
siguientes.
Para el circuito de retardo:
q(t) = z(t − Θ),
donde Θ debe coincidir con el período de presen-
tación de los estímulos (bits) a la entrada. Es decir,
el acarreo que en cada momento hay que sumar es
el que se haya podido generar en la suma de los
bits precedentes.
En la especificación de la etapa de sumador no
se ha indicado explícitamente que las variables
son función del tiempo (s(t), e1 (t), etc.). Pode-
mos proceder así porque este componente no tiene
«memoria»: su respuesta en un instante depende
solamente de las entradas en ese instante (desde el
15
e1
etapa de s
e2
sumador
z
q
elemento de
−
retardo, O
Figura 0.15. Sumador binario serial: modelo estructu-
ral.
punto de vista electrónico, es un «circuito combi-
nacional»).
Finalmente, veamos el modelo procesal de este
sumador binario serial. Más arriba hemos definido
el concepto de «estado» como «información míni-
ma necesaria en un instante dado para, conociendo
la evolución de los estímulos a partir de ese instan-
predecir el valor que toma la salida cuando se pre-
si ha habido acarreo anteriormente o no. Es decir,
el sistema puede estar en uno de dos estados po-
sibles, que podemos representar con los símbolos
q0 (correspondiente a q = 0, no acarreo previo) y
q1 (correspondiente a q = 1). El espacio de esta-
dos es finito, y consta sólo de dos «puntos» (dos
estados concretos):
Q = {q0 , q1 }
El conjunto de estímulos diferentes también es
finito:
E = {00, 01, 10, 11}
así como el de respuestas:
S = {0, 1}
Como decíamos antes, dados el estado actual y
el estímulo, la función de transición, f (e, q), de-
be dar el estado siguiente, y la función de salida,
g(e, q), la respuesta. Por ejemplo, si hay acarreo
(q = 1) y el estímulo es e1 = 1, e2 = 0, la res-
puesta debe ser s = 0 y el acarreo z = 1, es de-
cir: g(10, 1) = 0, f (10, 1) = 1. Un análisis ex-
16
haustivo de las 4 × 2 = 8 combinaciones posibles
de entradas y estados nos permite especificar com-
pletamente las funciones f y g. En la Figura 0.16
aparece esta especificación en dos formas equiva-
lentes: como una tabla de transiciones y como un
diagrama de transiciones.
e hacer estos comentarios:
q 00 01 10 11
q0 q0 /0 q0 /1 q0 /1 q1 /0
q1 q0 /1 q1 /0 q1 /0 q1 /1
00/0 01/0
11/0
01/1
q q
0 1
00/1
11/1
10/1
Figura 0.16. Sumador binario serial: modelo procesal.
La tabla indica los ocho valores de la función
f (los escritos delante de los símbolos «/») y los
ocho valores de g (los escritos detrás). En el dia-
grama, los círculos corresponden a estados, y los
arcos a transiciones entre estados; cada arco, eti-
quetado «e1 e2 /s», corresponde a una transición de
un estado a otro (que puede ser el mismo) debida
a la entrada (e1 , e2 ), generándose la salida s.
Los tres modelos (funcional, estructural y pro-
cesal) son tres formas distintas de describir al mis-
mo sistema. Dependiendo de lo que se pretenda
puede ser más interesante uno u otro. Así, desde
un punto de vista de «usuario» (un diseñador de un
sistema de nivel superior, en el que se utiliza éste
como componente o subsistema), lo que importa
es el modelo funcional (incluido el parámetro Θ).
Pero desde un punto de vista de «diseñador» los
modelos más útiles son el estructural y el proce-
sal.
Lección 0. Modelos y niveles
Ejemplo 4: un programa de ordenador
Volvamos al ejemplo del Apartado anterior so-
bre el modelo estructural de un programa para or-
denador (Figura 0.8(c)) cuyo modelo funcional es
«resultado = factorial(dato)». El modelo procesal
puede verse en la Figura 0.17, sobre la que cabe
1. Inicialmente, mientras el ordenador no empiece
a ejecutar el programa, el proceso no existe. El
modelo procesal incluye un estado inicial para
esta situación al que llamamos nonato.
2. En cuanto el programa empieza a ejecutarse, el
proceso pasa al estado activo, pero durante un
10/0
tiempo muy pequeño, porque lo primero que
hace es «pedir» un dato.
3. La unidad («periférico») por la que se introduce
el dato (el teclado, por ejemplo), es mucho más
lenta que la unidad de procesamiento. Mientras
no se haya terminado de leer el dato, el proceso
no puede continuar: está bloqueado.
4. Una vez obtenido el dato, el proceso vuelve a
estar activo. Durante este segundo estado ac-
tivo el programa hace la transformación a la
representación interna, llama a la función, és-
ta calcula el factorial y el programa traduce el
resultado a la representación a escribir por la
pantalla.
5. De nuevo el proceso pasa a bloqueado, ahora
esperando a que el resultado quede escrito.
6. Terminada la salida del resultado, el proceso
vuelve a estar activo (seguramente, y como al
principio, por muy poco tiempo).
7. Como el proceso ha terminado, pasa al estado
muerto.
Éste es un modelo procesal para un programa
concreto. En el Apartado 17.9 estudiaremos un
modelo genérico, de gran importancia para el es-
tudio del funcionamiento del ordenador durante la
ejecución de programas.
0.4 Ejemplos de sistemas y modelos
nonato
activo bloq.
dato
introducido
activo bloq.
resultado
escrito
activo
muerto
Figura 0.17. Modelo procesal del ordenador durante el
proceso del cálculo del factorial.
Ejemplo 5: una casa encantada
«Querido amigo:
Al poco de comprar esta vieja mansión me sor-
prendió desagradablemente el comprobar que es-
tá hechizada con dos sonidos de ultratumba que
la hacen prácticamente inhabitable: un canto pi-
caresco y una risa sardónica.
Aún conservo, sin embargo, alguna esperanza,
pues la experiencia me ha demostrado que su com-
portamiento obedece a ciertas leyes, oscuras pero
infalibles, que permiten modificarlo tocando el ór-
gano y quemando incienso.
En cada minuto, cada sonido está presente o
ausente. La situación en el minuto siguiente es así:
El canto conserva el mismo estado (presente o
ausente) salvo si en el minuto actual no se oye la
risa y toco el órgano, en cuyo caso el canto pasa
al estado opuesto.
17
En cuanto a la risa, si no quemo incienso, apa-
rece o no según que el canto estuviese presente o
ausente (de modo que la risa imita al canto con un
minuto de retardo). Ahora bien, si quemo incien-
so la risa hace justamente lo contrario de lo que
hacía el canto.
En el momento en que le escribo estoy oyendo
a la vez la risa y el canto. Le quedaré sumamente
agradecido si me aconseja sobre las manipulacio-
nes de órgano e incienso que debo realizar para
restablecer definitivamente la calma.»
El comportamiento que describe esta carta (tra-
ducida de un inolvidable libro de Ross Ashby26 )
caracteriza a un sistema cuyas entradas y salidas
se pueden formalizar con variables binarias: I, O
(entradas), R y C (salidas) (I = 0 si no se que-
ma incienso, I = 1 si se quema, etc.). El mismo
texto de la carta es ya un modelo funcional, que se
puede formalizar con el lenguaje de la lógica:
párrafo 4: Ct+1 = Ct ⊕ (Rt · Ot )
párrafo 5: Rt+1 = It ⊕ Ct
También podemos establecer un modelo estruc-
tural, considerando dos componentes, los agentes
que generan la risa y el canto, y las influencias mu-
tuas entre ellos y con las entradas. Del texto de
la carta se deduce el diagrama causal de la Figu-
ra 0.18.
I O
R C
Figura 0.18. Modelo estructural (diagrama causal) de
la casa encantada.
26
W.R. Ashby: An Introduction to Cybernetics. Chapman
and Hall, Londres, 1956. Traducción de J. Santos: Introduc-
ción a la cibernética. Nueva Visión, Buenos Aires, 1960.
18 Lección 0. Modelos y niveles

Pero el más interesante para este ejemplo es un e : no O y no I

0
modelo procesal que, como veremos, conduce in-
mediatamente a una solución del problema. q
0
R y C son las variables de estado (además de no R,
no C
e : O y no I
ser las de salida). En efecto, según explican los pá- e2 : no O y no I
e :OeI 0
rrafos 4 y 5 de la carta, basta con saber qué valor 3
e : no O y no I e : no O e I
tienen esas variables en un minuto determinado y e0 : O y no I 1 e : no O e I
2 e :OeI e1 : O e I
q 3 q 3
qué estímulos (valores de I y O) se dan en ese mi- 3 2
R, C e : O y no I R, no C
nuto para conocer los valores que tomarán R y C 2

en el minuto siguiente.
El espacio de estados consta de cuatro estados:
• q0 , correspondiente a R = 0, C = 0 (no se oye
la risa ni el canto)
• q1 , correspondiente a R = 0, C = 1 (no se oye
la risa, sí el canto)
• q2 , correspondiente a R = 1, C = 0 (se oye la
risa, no el canto)
• q3 , correspondiente a R = 1, C = 1 (se oyen
la risa y el canto)
En cada uno de estos cuatro estados pueden
aplicarse cuatro estímulos diferentes:
• e0 : O = 0, I = 0 (no tocar el órgano ni quemar
incienso)
• e1 : O = 0, I = 1 (no tocar el órgano pero
quemar incienso)
• e2 : O = 1, I = 0 (tocar el órgano pero no
quemar incienso)
• e3 : O = 1, I = 1 (tocar el órgano y quemar
incienso al mismo tiempo)
Pues bien, basta considerar detenidamente los
párrafos 4 y 5 de la carta para especificar por com-
pleto la función de transición, es decir, para deter-
minar las 4 × 4 = 16 transiciones entre estados. El
resultado, en forma de diagrama de transiciones,
puede verse en la Figura 0.19.
A la vista de este diagrama, la solución al pro-
blema que plantea la carta aparece fácilmente: el
estado inicial es q3 ; de él se puede pasar a q1 me-
diante e1 o e3 , y de éste a q0 mediante e3 . Expre-
sándolo en los mismos términos epistolares: «Du-
rante un minuto, queme usted incienso, y, si le ape-
tece, toque también el órgano; desaparecerá la ri-
e : no O
0 y no I
e :OeI e : O y no I
e3 : no O e I 2
1 q
1
no R, C
e : no O e I
1
Figura 0.19 Modelo procesal de la casa encantada.
sa. Durante el minuto siguiente, siga quemando in-
cienso y póngase a tocar el órgano, si es que no lo
estaba haciendo ya. Transcurrido este minuto, cese
toda actividad. Si no vuelve a manipular ni el ór-
gano ni el incienso, se habrá librado para siempre
del encantamiento».
Hemos considerado como salidas R y C, que
son también las variables de estado (por este mo-
tivo, en este caso las ecuaciones de estado son
las mismas ecuaciones del modelo funcional escri-
tas más arriba). Alternativamente, podríamos ha-
ber definido una salida binaria, s, que representase
la presencia o ausencia de algún sonido27 :
• s = 0 si no hay ningún sonido (R = 0, C = 0)
• s = 1 si hay algún sonido
El lector puede ver en el diagrama otras solucio-
nes (con secuencias de estímulos más largas que la
propuesta). También puede observar que, afortu-
nadamente para el propietario de la casa, el estado
q0 (el único con s = 0) es estable para la entra-
da e0 .
27
Aquí, a diferencia del caso del sumador, podemos aso-
ciar la salida a los estados, no a las transiciones: s = 0 está
asociada a q0 , y s = 1 a los otros tres. La función de salida
es g(q), no g(e, q).
0.5 Pragmática
0.5. Pragmática
Analicemos ahora la vertiente pragmática de los
modelos. Un modelo de un sistema puede servir a
la persona que hace uso de él para varios fines:
• Utilizar el sistema. Esto es, saber qué estímulos
tiene que aplicarle para obtener un comporta-
miento deseado. En este caso normalmente in-
teresa disponer de un modelo funcional, pero
(como pone de manifiesto el último ejemplo) a
veces puede resultar más útil un modelo proce-
sal.
• Diseñar, rediseñar, implementar, reparar o man-
tener el sistema. En estas actividades suele do-
minar el uso de modelos estructurales y proce-
sales. El modelo funcional es la «entrada» a la
actividad. Pero ocurre con frecuencia que es-
te modelo no está formalizado, y se hace ne-
cesario pasar por una fase previa en la que se
establecen las especificaciones formales, como
veremos más adelante.
• Simplemente, comprender el sistema. La mo-
tivación puede ser pura curiosidad científica, o
un paso previo para alguna de las actividades
anteriormente enunciadas. Por ejemplo, en este
libro presentamos modelos pensados para que
el lector comprenda los ordenadores. El objeti-
vo final es que el lector se convierta en (o per-
feccione sus habilidades como) usuario y/o di-
señador de ordenadores o de sistemas construi-
dos con él (así lo esperamos). Para una com-
prensión cabal del sistema hay que estudiar mo-
delos funcionales, estructurales y procesales.
Artefactos y herramientas
Un ordenador es un artefacto: algo hecho con
arte. El diseño de ordenadores tiene, en efecto,
mucho de «artístico». Al mismo tiempo, un orde-
nador es una herramienta: un objeto que ayuda en
la resolución de problemas (entre los cuales se en-
cuentra el diseño de artefactos, ordenadores inclui-
dos).
19
En general, un artefacto28 es un sistema ma-
terial o conceptual concebido y construido por el
hombre, y una herramienta29 es un artefacto que
tiene un fin específico: el de usarlo como ayuda
para la resolución de ciertos problemas. Un auto-
móvil y un edificio son (como el ordenador) arte-
factos y herramientas, y también lo son, aunque se
trate de sistemas conceptuales, la lógica y las teo-
rías matemáticas. Las obras de arte son artefactos,
pero, normalmente, no son herramientas. Todas las
herramientas son artefactos (si excluimos las «he-
rramientas primitivas» que se encuentran en la na-
turaleza). Los sistemas naturales no son artefactos,
y, por tanto, tampoco herramientas (aunque a ve-
ces se usen como si lo fueran)30 .
Las intenciones y las motivaciones de las perso-
nas que tratan con un mismo artefacto (y, en gene-
ral, con un mismo sistema) pueden ser muy varia-
das. De ahí que el mismo sistema pueda verse de
muchas maneras diferentes, o, lo que es igual, que
puedan formularse diferentes tipos de modelos en
diferentes niveles de abstracción.
Adecuación de los modelos
Ya sabemos que toda descripción de un siste-
ma es un modelo de ese sistema. Distintos obser-
vadores, contemplando la misma realidad, pueden
elaborar o encontrar útiles descripciones muy di-
ferentes para esa realidad. Ello no implica necesa-
riamente que unas descripciones se ajusten más o
menos que otras a la realidad. La mejor descrip-
ción para una determinada persona en un determi-
nado momento no es la más completa ni la más de-
tallada, sino, simplemente, la que mejor le permite
a esa persona resolver el problema que se plantea
en ese momento.
28
«1. Obra mecánica hecha según arte. 2: Máquina, apara-
to» (D.R.A.E.)
29
«1. Instrumento, por lo común de hierro o acero, con que
trabajan los artesanos» (D.R.A.E.)
30
Estas afirmaciones, como algunas otras de esta Lección,
son matizables y cuestionables. En particular, los bien cono-
cidos avances biológicos recientes empiezan a difuminar los
límites entre «artefacto» y «sistema natural».
20
Un sistema natural particularmente complejo es
el hombre. Si se nos pide una descripción de una
persona determinada seguramente daremos una re-
lación de sus rasgos fisionómicos más destaca-
dos, es decir, un modelo estático y de «caja ne-
gra» (funcional). Para más detalles, trataríamos de
describir su «personalidad», que incluye rasgos
de comportamiento dinámico, y al hacerlo formu-
laríamos de manera informal e incompleta algún
modelo procesal («le gusta tal cosa, le enfada tal
otra...»). Pero el hombre, como sistema, es objeto
de estudio de diversas ciencias, y en cada una de
ellas se han elaborado distintos modelos. La psico-
logía conductista, por ejemplo, utiliza sobre todo
modelos funcionales con los que estudia las res-
puestas humanas ante los estímulos, mientras que
la psicología cognoscitiva trata con modelos de re-
presentación del conocimiento en la mente huma-
na (modelos estructurales) y de procesamiento de
la información (modelos procesales). En medicina
se utilizan modelos estructurales estáticos (anato-
mía) y funcionales y procesales dinámicos (fisio-
logía). Para un sociólogo, el hombre es un compo-
nente de los sistemas sociales, caracterizado por
ciertos rasgos de comportamiento (por tanto, por
algún modelo funcional), y para un ingeniero pue-
de ser el objeto último de su profesión (conside-
rando que el objetivo de la ingeniería es la pro-
ducción de artefactos que redunden en la mejora
de la calidad de vida), un objeto inmediato (dise-
ño ergonómico de interfaces hombre–máquina), o,
incluso, una fuente inspiradora de modelos (en la
línea de lo que algunos llaman «biónica»). En ca-
da caso, el criterio para elegir una descripción (un
modelo) y descartar otras depende, sobre todo, de
la adecuación de esa descripción al tipo de proble-
mas que se pretende abordar con ella.
Como ejemplo de artefacto tomemos el auto-
móvil. Para el usuario normal el automóvil es una
herramienta, y su mejor descripción es un mode-
lo funcional: le basta con saber cómo responde el
vehículo ante los «estímulos» de girar el volan-
te, pisar el freno, etc. Algunos usuarios especia-
les, como los pilotos de pruebas, pueden requerir
Lección 0. Modelos y niveles
modelos funcionales más detallados31 . Pero para
los profesionales de la industria del automóvil és-
te no es ya una herramienta, sino el objeto central
de su trabajo. En las actividades ligadas al diseño,
en general, no bastan los modelos funcionales, y
se hacen necesarios modelos estructurales y pro-
cesales, diferentes para cada especialidad.
Los modelos para la comprensión son general-
mente conceptuales, más o menos formalizados,
aunque en ocasiones la comprensión se facilita
mediante la presentación de un modelo analógico
(por ejemplo, cuando se explican los rudimentos
de la electricidad mediante un «símil hidrodinámi-
co»). A veces, buscando la mejor forma de comu-
nicar ideas, se mezclan en un mismo diagrama
componentes de modelos estructurales y procesa-
les. Así ocurre en este libro, en las Figuras 3.15,
3.16, 20.4 y 20.9.
Los típicos modelos para uso son los «manua-
les de usuario»; generalmente se trata de descrip-
ciones informales, pero como veremos enseguida
el usuario del sistema puede ser un diseñador de
otro sistema (de «nivel superior»), y en tal caso se
hacen necesarios modelos formalizados.
La actividad de diseño
El término «diseño» se aplica tanto en la inge-
niería como en actividades muy distantes de ella
en el plano axiológico (los valores esenciales en
esas actividades son de naturaleza estética) y en
otras de naturaleza «mixta» (arquitectura, urbanis-
mo...)32 . Todas estas actividades comparten una
orientación creativa, la idea de ensamblar partes
para construir un sistema con ciertos fines.
El objeto de la actividad de diseño es siempre
31
Es bien sabido que todos los usuarios pueden, en ocasio-
nes, beneficiarse del conocimiento de modelos estructurales
y procesales. Pero cuando un usuario recurre a uno de estos
modelos es por una de dos razones: o bien porque su modelo
funcional no es suficiente para resolver todos sus problemas,
o bien porque deja de ser estrictamente un usuario (como ocu-
rre cuando el conductor abre el capó).
32
«Diseño: [...] 3. Concepción original de un objeto u obra
destinados a la producción en serie» (D.R.A.E.).
0.5 Pragmática
un artefacto. Son artefactos un automóvil, un or-
denador, un programa, un edificio..., pero también
un sistema axiomático, un sistema de transporte,
un sistema social... Puede discutirse si el diseño
del segundo tipo de sistemas es «ingeniería», pero
hay principios y herramientas que son de utilidad
en el diseño de ciertos tipos de sistemas y que pue-
den extenderse a otros.
En el proceso de diseño se pueden utilizar como
herramientas sistemas materiales o conceptuales.
La herramienta material más general y flexible es
el ordenador, que, con técnicas de simulación y vi-
sualización, permite prever el funcionamiento del
sistema que se está diseñando; esto es lo que se lla-
ma CAD («Computer-Aided Design»: diseño asis-
tido por ordenador). Las herramientas conceptua-
les son las teorías, metodologías y modelos dispo-
nibles para el tipo de artefacto a diseñar.
El diseño de un artefacto suele incluir muchas
facetas, y con frecuencia sólo se dispone de mode-
los formalizados y sustentados por una teoría para
algunas de ellas. Esta carencia se suple con heu-
rísticos: «trucos» o reglas empíricas cuya utilidad
está avalada por la experiencia.
Usuarios y diseñadores
El ordenador se puede considerar como una he-
rramienta (punto de vista del usuario) o como un
artefacto a construir (punto de vista del diseñador).
Pero esta diferenciación no es tan neta como a pri-
mera vista pudiera parecer: el diseñador de progra-
mas de aplicación es usuario de un sistema opera-
tivo; el diseñador de éste es usuario de una máqui-
na hardware, diseñada haciendo uso de placas, que
están construidas con circuitos integrados... Cada
una de estas personas necesita modelos adecuados
para ejercer su actividad: en general, el usuario de
un sistema necesita un modelo funcional de ese
sistema, y utiliza modelos estructurales y procesa-
les de los sistemas que diseña con él.
21
Diseño, implementación y especificaciones
En las actividades ligadas a la concepción y
construcción de un artefacto es útil distinguir en-
tre diseño e implementación. El diseño comien-
za con una descripción de las funciones pretendi-
das (un modelo funcional) del sistema, y termina
con una descripción de los componentes abstrac-
tos y sus interrelaciones y procesos (modelos es-
tructural abstracto y procesal). En la implementa-
ción se materializa el modelo estructural en otro
cuyos componentes son concretos. La Figura 0.20
(que el lector debe situar en el contexto de la Figu-
ra 0.3) muestra los tipos de modelos más ligados a
cada actividad.
artefacto
(original)
modelo modelo modelo
funcional estructural procesal
usuario implementador diseñador
Figura 0.20. Modelos de artefactos más adecuados se-
gún la pragmática.
Además de su utilidad dentro de cada actividad,
los modelos también son vehículos de comunica-
ción entre unas actividades y otras. Cuando sirven
a esta función, los modelos suelen llamarse espe-
cificaciones. Y, para reducir al mínimo posible los
errores de comunicación, conviene que estos mo-
delos estén expresados en un lenguaje formal. Se
habla entonces de especificaciones formales.
Para ilustrar lo anterior, volvamos al ejemplo
del sumador binario. Partiendo de su especifica-
ción funcional, el resultado del diseño es el mode-
lo procesal de la Figura 0.16 y el estructural de la
Figura 0.15. La implementación en este caso con-
sistiría en buscar los componentes físicos (siste-
mas electrónicos digitales) que tengan las funcio-
22
nes requeridas por el modelo estructural. Un hecho
interesante aparece aquí: al bajar el nivel de abs-
tracción, en la implementación pueden ponerse de
manifiesto restricciones físicas que obligan a vol-
ver sobre las especificaciones del diseño. Así, en la
especificación funcional podría haberse decidido
un determinado valor, muy pequeño, del paráme-
tro Θ (intervalo entre presentación de los bits). En
el modelo estructural procedente del diseño, este
valor es el que debe tener el «elemento de retar-
do». Pero supongamos, ya en la implementación,
que al buscar un componente electrónico que ma-
terialice a este elemento33 , no encontramos nin-
guno con ese valor tan pequeño34 . En este caso
sencillo no hay más solución que relajar las espe-
cificaciones (conformándose con un sistema más
lento); en otros, en los que existen modelos alter-
nativos, es posible rehacer el diseño de modo tal
que la implementación sea factible.
La implementación no siempre consiste en
construir un modelo estructural con componentes
físicos. El caso más notorio es el que se da en pro-
gramación. Para el diseño de un programa se parte
de unas especificaciones funcionales y se llega a
un modelo estructural de componentes abstractos,
definido cada uno por su función. Así, en el ejem-
plo del programa para el cálculo del factorial se
podría llegar a la descomposición en componen-
tes o módulos que resumía la Figura 0.18(c). Pa-
ra programas complejos esta descomposición mo-
dular es recursiva: para cada módulo se estable-
cen un modelo estructural y un modelo procesal,
cada componente del modelo estructural vuelve a
descomponerse, y así sucesivamente hasta llegar
a funciones simples. En cualquier caso, el mode-
lo estructural resultante incluye módulos defini-
dos funcionalmente. La implementación consiste
en este caso en plasmar esas funciones abstrac-
tas en construcciones concretas con un lenguaje de
programación.
33
Un biestable, como se explica en el Apéndice B.
34
O bien lo encontramos pero a un coste prohibitivo. El
criterio de coste, aquí omitido, forma parte importante de las
especificaciones iniciales del diseño.
Lección 0. Modelos y niveles
Productos y ciclo de vida
Hemos visto, con un ejemplo sencillo (el del su-
mador binario), que, como resultado de la imple-
mentación, puede ser necesario rehacer las especi-
ficaciones para el diseño. Pero también es preciso
replantearse las especificaciones iniciales cuando
el diseño es para un producto.
Entendemos por «producto» un artefacto que
se obtiene como resultado de un proceso de fabri-
cación. Es decir, no sólo es un sistema diseñado
e implementado por el hombre; este diseño y esta
implementación están condicionados por la exis-
tencia de un mercado y, frecuentemente, de una
normativa. Cuando el artefacto es un producto, el
resultado de la implementación es un prototipo,
que debe someterse a pruebas antes de su produc-
ción o fabricación. Como resultado de estas prue-
bas, y también a lo largo de la vida del producto,
es posible que aparezca de nuevo la necesidad de
un rediseño.
La Figura 0.21 ilustra esta naturaleza recurren-
te de las actividades ligadas a la conceptuación,
la construcción y el uso de un producto. El mode-
lo conceptual es una descripción de las funciones
que se desean en el sistema, y el diseño consis-
te en elaborar modelos estructurales y procesales
para que el sistema satisfaga esas especificaciones
funcionales.
La sucesión de fases por las que pasa un pro-
ducto desde su conceptuación hasta su abandono
por obsolescencia o envejecimiento se llama ciclo
de vida. La Figura 0.21 representa un modelo muy
general de ciclo de vida. En áreas particulares de
la ingeniería se han propuesto ciclos de vida es-
pecializados para los distintos tipos de productos.
Así, en la ingeniería del software un ciclo de vida
«clásico» es el formado por las fases sucesivas de
captura de requisitos (correspondiente, aproxima-
damente, a la «conceptuación» de la Figura 0.21),
diseño, codificación (que corresponde a «imple-
mentación»), depuración y validación (pruebas),
y mantenimiento.
0.6 Jerarquías de abstracciones 23

sus consecuencias.
conceptuación Ya hemos hablado de «sistemas», «compleji-
dad» y «modelos», hemos visto tres tipos básicos
de modelos conceptuales para sistemas dinámi-
cos (funcionales, estructurales y procesales), he-
modelo conceptual
(funcional) mos explicado que las descripciones son modelos
y que a un mismo sistema pueden aplicársele des-
cripciones diversas por consideraciones pragmáti-
cas. Aclaremos ahora lo que pretendemos signifi-
diseño car con «niveles» y «jerarquía de abstracciones».
En general en este Apartado, y particularizando
para los ordenadores en el siguiente.
modelos estructural
y procesal
Modelos y abstracciones
La modelación y la abstracción son actividades
implementación intelectuales indisolublemente unidas. En efecto,
el modelo sólo representa los rasgos de interés del
original, es decir, hace abstracción de los que no
son pertinentes para el propósito del modelo.
prototipo En el ejemplo del sumador binario serial abs-
traíamos detalles como los valores de las tensio-
nes eléctricas que puedan corresponder a «0» y a
«1», o como el hecho de que los cambios (de «0» a
pruebas
«1» y de «1» a «0») no son instantáneos, sino que
«en realidad»35 son graduales, con un tiempo de
transición. Igualmente, abstraíamos, en su modelo
producto
estructural, la composición de los dos bloques que
lo forman, definiéndolos por sus modelos funcio-
nales. Si entramos en su composición, descende-
mos de nivel de abstracción.
uso

Jerarquías de niveles de abstracción

Figura 0.21 Ciclo de vida de un producto.
0.6. Jerarquías de abstracciones
Un ordenador es un sistema complejo que puede
describirse mediante diferentes modelos, en distin-
tos niveles de una jerarquía de abstracciones. Ésta
era nuestra declaración inicial, y el objetivo de es-
ta Lección es profundizar en su significado y en
Acabamos de sugerir que un mismo sistema
puede describirse no sólo con distintos modelos,
sino también en distintos niveles de abstracción.
35
Entre comillas, porque los cambios se describen como
graduales, o como funciones continuas del tiempo, en un ni-
vel de abstracción inferior, pero si aún descendemos más en
el nivel de abstracción y aplicamos modelos de la física cuán-
tica nos encontramos «en realidad» con cambios nuevamente
discretos. No olvidemos la precaución acerca del modelo y la
realidad, mencionada en el párrafo sobre sistemas complejos.
24
Pensar en distintos niveles de abstracción es ha-
bitual en las ciencias que tratan con sistemas com-
plejos. Por ejemplo, en las ciencias biológicas se
estudian los niveles bioquímico (biología molecu-
lar), de célula (citología), de tejido (histología), de
órgano (anatomía) y de organismo. En cada nivel
se utilizan los tres tipos de modelos que hemos ex-
plicado (aunque no con esos nombres). Así, en el
nivel de célula la morfología celular utiliza mode-
los estructurales (describe a las células como en-
samblajes de subsistemas), la fisiología celular uti-
liza modelos procesales (describe los procesos in-
ternos que explican el metabolismo, el crecimien-
to, la división, etc.) y desarrolla modelos funcio-
nales que son de utilidad para el estudio en los ni-
veles superiores.
En general, un nivel de abstracción para la des-
cripción de un sistema se caracteriza por:
• La naturaleza de las variables que representan
a las magnitudes (estímulos, respuestas y esta-
dos) de interés: pueden ser continuas o discre-
tas, numéricas o simbólicas.
• El espacio de estados en el que se formulan
modelos procesales.
• Los componentes que permiten establecer mo-
delos estructurales. Estos componentes estarán
descritos como modelos funcionales de siste-
mas del nivel inferior.
• Las leyes de composición que rigen la manera
de interconectar componentes.
• Las leyes de comportamiento que determinan
el comportamiento (modelo funcional) de un
sistema a partir de su modelo estructural y de
los modelos funcionales de los componentes, o
bien a partir de su modelo procesal.
• El lenguaje (o lenguajes) con el que expresa-
mos las leyes y formulamos modelos.
Entre estos niveles existe una relación de orden:
los componentes de los modelos estructurales del
nivel i son sistemas del nivel i − 1. El sistema «fi-
nal» (aquél para el que se construye la jerarquía)
viene descrito por los modelos del más alto nivel.
«Descender» (pasar del nivel i al i − 1) en la je-
Lección 0. Modelos y niveles
rarquía es concretar detalles, y «ascender» es abs-
traer. Cuando la jerarquía corresponde a un arte-
facto, y se utiliza para su construcción, la imple-
mentación de sistemas del nivel i implica un «des-
censo» al nivel i − 1.
0.7. Jerarquía de niveles para los
ordenadores
La Figura 0.22 presenta los siete niveles de la
jerarquía en la que situaremos a las descripciones
de los ordenadores. Antes de pasar a comentarlos,
haremos dos precisiones:
• Salvo alusiones esporádicas, tanto aquí como
en el resto del libro nos limitaremos a aquellas par-
tes de los ordenadores que tienen un soporte tecno-
lógico electrónico, eludiendo todo lo concerniente
a tecnologías mecánica, magnética y óptica utili-
zadas en terminales y memorias, que precisarían
de otras jerarquías de descripción en los niveles
«bajos» de la Figura 0.22.
• En esta jerarquía se hace referencia a modelos
que son precisamente el objeto de estudio de es-
te curso. Por tanto, no se puede pretender que sea
comprensible en una primera lectura. Este Aparta-
do debería ser objeto de repaso recurrente tras el
estudio de cada una de las partes del libro.
Los niveles
El nivel más bajo (el de menor abstracción) es el
de dispositivo. En él se estudian los sistemas elec-
trónicos básicos (transistores, resistores, conden-
sadores, etc.) que son componentes del siguiente
nivel. En este nivel, los componentes son los ma-
teriales semiconductores, y el lenguaje para expre-
sar las interrelaciones y los procesos es el de la fí-
sica del estado sólido. (Aquí, si hubiéramos de in-
cluir los detalles no electrónicos a que nos refería-
mos en el párrafo anterior, consideraríamos otros
componentes, como soportes magnéticos, ópticos
y mecánicos).
0.7 Jerarquía de niveles para los ordenadores 25

NIVELES COMPONENTES SISTEMAS

máquinas simbólicas
máquina simbólica (interpretan sentencias
+programas y órdenes en
lenguajes simbólicos)

máquinas programables
máquina operativa binarias extendidas
+programas (interpretan instrucciones
y "llamadas al sistema")

máquinas programables
máquina convencional binarias
+microprogramas
implementación

(interpretan instrucciones)
abstracción

micromáquina máquinas microprogramables

(interpretan
microinstrucciones)

sistemas combinacionales
circuito lógico y secuenciales,
memorias, ...

circuito eléctrico puertas lógicas

metales, transistores,
dispositivo semiconductores, ... resistores, ...

Figura 0.22 Niveles de descripciones para los ordenadores.

Los componentes del nivel de circuito eléctri-
co son los sistemas del anterior, es decir, lo que
en la terminología de la electrónica se llaman,
justamente, «componentes» (discretos): resistores,
transistores, etc. Se utilizan aquí lenguajes gráfi-
cos para indicar las interrelaciones o conexiones
entre los componentes, y para expresar el compor-
tamiento de estos componentes y de las estructu-
ras (curvas tensión–corriente, cronogramas de las
evoluciones de las variables, etc.), así como el len-
guaje del álgebra para expresar las leyes de la elec-
tricidad.
En el nivel de circuito lógico se abstrae la es-
tructura de ciertos sistemas construidos en el nivel
anterior: las puertas lógicas. Además, y paralela-
mente, se abstrae también la naturaleza física de
las variables: ya no se trabaja con valores de ten-
sión o de corriente, expresados en voltios o ampe-
rios, sino con «niveles lógicos» («alto» y «bajo»,
o «0» y «1»). Este nivel puede descomponerse en
dos subniveles: el de circuito combinacional y el
de circuito secuencial. En efecto, para el diseño de
circuitos secuenciales se toman como componen-
tes sistemas combinacionales, como los biestables,
diseñados con puertas. El lenguaje predominante
en este nivel es el del álgebra de Boole. El nivel
de circuito lógico no forma parte del contenido de
este curso, pero los conceptos más importantes se
presentan en el Apéndice B.
Los niveles «bajos» no son exclusivos de la des-
cripción de ordenadores: son muchos los artefac-
tos electrónicos digitales diseñados en el nivel de
26
circuito lógico que no son programables o que, aun
siéndolo, no son de propósito general (característi-
cas ambas que son esenciales de los ordenadores).
En tales sistemas es obvio que no tiene sentido
abstraer por encima del nivel de circuito lógico.
El siguiente nivel es ya característico de los or-
denadores: el nivel de micromáquina. Sus com-
ponentes son registros (elementos en los que se
puede registrar y recuperar una información bina-
ria de longitud fija), operadores aritméticos y ló-
gicos (que permiten transformar una información
o combinar varias para dar un resultado), unida-
des de memoria (que almacenan un conjunto de
informaciones), secuenciadores (que generan se-
ñales secuenciadas en el tiempo para gobernar a
otros componentes) y otros circuitos combinacio-
nales y secuenciales considerados como cajas ne-
gras, así como los buses, que permiten interconec-
tar a los elementos. Un componente central en es-
te nivel es la memoria de control, que almacena
microinstrucciones. Los modelos procesales des-
criben las secuencias en el tiempo de transferen-
cias de conjuntos de bits entre registros y memo-
rias; estas transferencias están determinadas por
las microinstrucciones almacenadas en la memo-
ria de control. Los modelos funcionales describen
las microinstrucciones que acepta la micromáqui-
na y sus efectos.
En el nivel de máquina convencional (o, sim-
plemente, nivel de máquina) el modelo funcional
de un ordenador está compuesto por su repertorio
de instrucciones y los convenios de representación
de la información. Tanto las instrucciones como
las otras informaciones se expresan en binario (ca-
denas de ceros y unos), que es el lenguaje predo-
minante en este nivel. En los modelos estructurales
se abstrae el hecho de que exista una memoria de
control con microinstrucciones; se considera inte-
grada en un componente, la unidad central de pro-
cesamiento, que en el nivel de micromáquina se
descompone en circuitos aritméticos, memoria de
control, etc. Combinando instrucciones (es decir,
programando) se construyen sistemas de niveles
superiores.
Lección 0. Modelos y niveles
El nivel de máquina operativa (el de un orde-
nador acompañado de un sistema operativo) surge
como necesidad de «arropar» al «ordenador des-
nudo» (máquina convencional) con programas de
uso general que lo hagan más fácil de utilizar y
que optimicen su funcionamiento. El modelo fun-
cional de un ordenador en este nivel incluye al
modelo funcional del nivel de máquina y lo am-
plía con «instrucciones virtuales» (esencialmente,
llamadas al sistema operativo). Este nivel y el si-
guiente son ya niveles de máquinas virtuales, en el
sentido de que las funciones del sistema se imple-
mentan mediante una combinación de hardware y
software. Pero en el nivel de máquina operativa el
lenguaje de la máquina sigue siendo binario.
Si sólo dispusiéramos de los niveles anteriores
la programación de los ordenadores sería una ar-
dua tarea debido al lenguaje binario. Para facili-
tarla, se inventaron los procesadores de lenguajes
(los clásicos intérpretes y compiladores de lengua-
jes de programación, y también los programas que
materializan a las interfaces de usuario), con los
que apareció un nivel nuevo: el de máquina sim-
bólica. Hay dos tipos de usuarios en este nivel (re-
finando la jerarquía, podríamos descomponerlo en
dos subniveles). Los programadores utilizan algún
procesador de lenguaje (además, desde luego, del
sistema operativo) que les permite trabajar con una
máquina virtual que «entiende» ese lenguaje. Los
usuarios finales trabajan con la máquina virtual
que resulta de ejecutar en la máquina operativa los
programas desarrollados por los programadores.
Las excepciones
Como todo modelo, la jerarquía presentada es
una aproximación a la realidad. Y como un mode-
lo que pretende ser un marco general para modelos
concretos de ordenadores, su aplicación a esos ca-
sos concretos presenta excepciones. Las más nota-
bles se dan en la abstracción del nivel de circuito
lógico al de máquina convencional (o, en sentido
contrario, en la implementación de éste). Según la
Figura 0.22, hay un nivel entre ambos, el de mi-
0.7 Jerarquía de niveles para los ordenadores
cromáquina. Pero, como veremos en la Segunda
Parte,
• a veces este nivel no existe: los sistemas del ni-
vel de máquina convencional se pueden imple-
mentar directamente con componentes que son
sistemas del nivel de circuito lógico (Aparta-
do 9.1), y
• a veces existe otro nivel adicional (el de «na-
nomáquina») entre el de micromáquina y el de
circuito lógico (Apartado 12.2).
La existencia de estos niveles está condicionada
por las tecnologías disponibles en cada momento
(en definitiva, por el nivel de dispositivo, que irra-
dia su influencia «hacia arriba»).
Conviene insistir en que esta jerarquía de nive-
les es un marco de referencia útil, pero no rígido ni
dogmático. De hecho, en la Segunda Parte de este
curso nos situaremos en un «nivel» intermedio que
no aparece en ella: el nivel de microarquitectura.
Es el mismo nivel de micromáquina cuando éste
existe, pero cuando la máquina convencional (es
decir, los sistemas descritos en el nivel de máqui-
na convencional) se implementa directamente con
circuitos lógicos, el nivel de microarquitectura sir-
ve para describir esa implementación abstrayen-
do detalles de tales circuitos. La diferencia entre
ambos niveles (micromáquina y microarquitectu-
ra) se verá claramente en el Apartado 12.7.
Abstracciones e implementaciones
Cuando «subimos» en la jerarquía hacemos abs-
tracción, mientras que al «bajar» entramos en de-
talles. La abstracción es obligada para describir a
un sistema en un determinado nivel. Y el entrar en
detalles es necesario cuando tenemos que imple-
mentar el sistema.
Los sistemas descritos funcionalmente (especi-
ficados mediante un lenguaje adecuado) en un de-
terminado nivel pueden implementarse de varias
formas. En los ordenadores, las formas típicas son
la implementación hardware, la implementación
software y una intermedia, la implementación fir-
27
mware36 . Los sistemas de los niveles inferiores
(circuito eléctrico y circuito lógico) se implemen-
tan siempre en hardware, mientras que los de los
niveles superiores (máquina simbólica y máqui-
na operativa) se suelen implementar mediante sof-
tware. El nivel de máquina convencional se puede
implementar en hardware o en firmware, como es-
tudiaremos en la Segunda Parte, pero también en
software (mediante un programa que, ejecutándo-
se en otra máquina, simule al sistema).
Si el lector tiene conocimientos sobre lenguajes
de programación ya sabe lo que son los compila-
dores y los intérpretes37 , utilizados para la imple-
mentación software de los niveles superiores. Así,
el nivel de máquina simbólica queda definido, fun-
cionalmente, por la sintaxis y la semántica de los
lenguajes de programación. Por ejemplo, la «má-
quina C» corresponde al lenguaje C, y se imple-
menta mediante un compilador de C que traduce
los programas al lenguaje binario de la máquina
operativa (o, muy raro pero no imposible en el ca-
so de este lenguaje, mediante un intérprete que se
ejecute en la máquina convencional). La máqui-
na simbólica definida por el lenguaje de órdenes
del sistema operativo se implementa mediante un
intérprete de este lenguaje. Y la máquina opera-
tiva definida por unas operaciones, las «llamadas
al sistema», que estudiaremos en la Tercera Par-
te, se implementa mediante programas intérpretes
que forman parte del sistema operativo. A veces
la implementación se hace mediante un proceso
de compilación seguido de otro de interpretación.
Así, un programa en Java se compila primero a un
lenguaje intermedio («bytecodes») y el resultado
se interpreta en una máquina convencional (Apar-
tado 22.4 y Lecciones 23 y 24).
36
En estas expresiones se adjetivan los sustantivos «har-
dware», «software» y «firmware»; sería quizás más correcto
decir «implementación mediante hardware», etc. En la Se-
gunda Parte estudiaremos con detalle el firmware, pero pode-
mos ya avanzar que está formado por microprogramas (con-
juntos de microinstrucciones) almacenados en una memoria
de control, y esto es lo que define el nivel de micromáquina.
37
En cualquier caso, estas ideas se presentan en la Lec-
ción 22.
28
0.8. Un último ejemplo: la «máqui-
na de von Neumann»
Los ordenadores tienen una larga «prehistoria»
(Apartado 0.12). Un hito importante fue la intro-
ducción del concepto de programa almacenado:
previamente a su ejecución, las instrucciones que
forman el programa deben estar guardadas, o al-
macenadas, en una memoria de acceso rápido. Es-
to condiciona fuertemente los modelos estructura-
les, funcionales y procesales de los ordenadores en
todos los niveles.
Modelos estructurales que contenían unidades
de memoria, de procesamiento, de control y de
entrada/salida se habían propuesto tiempo atrás,
pero la idea de tener el programa almacenado en
la memoria, y el modelo procesal que acompa-
ña a esta idea, se atribuye generalmente (y quizás
erróneamente, véase el Apartado 0.12) a John von
Neumann. Hay un documento escrito en 1946 por
Burks, Goldstine y von Neumann (cuando aún no
se había construido ninguna máquina de programa
almacenado) que mantiene hoy toda su vigencia
conceptual. Haciendo abstracción de los detalles
tecnológicos, esa descripción no ha sido superada,
pese a que seguramente se habrán publicado de-
cenas de miles de páginas explicando lo mismo.
Por eso, nos serviremos de ese texto, extrayendo y
glosando algunos de sus párrafos.
Unidades (subsistemas)
«... Puesto que el dispositivo final ha de ser
una máquina computadora de propósito general,
deberá contener ciertos órganos fundamentales
relacionados con la aritmética, la memoria de al-
macenamiento, el control y la comunicación con
el operador humano...».
Aquí el documento introduce el modelo estruc-
tural básico en el nivel de máquina convencio-
nal. Los «órganos» son los subsistemas denomi-
nados «UAL» (unidad aritmética y lógica), «MP»
(memoria principal), «UC» (unidad de control) y
Lección 0. Modelos y niveles
UCP
datos
UAL UE/S
datos
direcciones
MP
UC direcciones
instrucciones
instrucciones, y datos (operandos y resultados)
direcciones (de MP y de UE/S)
señales de control ("microórdenes")
Figura 0.23. Modelo estructural de la «máquina de von
Neumann».
«UE/S» (unidades de entrada y salida) en el esque-
ma de bloques de la Figura 0.23. Al conjunto de la
UC y la UAL se le llama «UCP» (unidad cen-
tral de procesamiento, o procesador central).
La tecnología electrónica actual permite encapsu-
lar la UCP (y parte de la MP, Apartado 15.7) en un
chip, y el resultado se llama microprocesador.
Programa almacenado y propósito general
«... La máquina debe ser capaz de almacenar
no solamente la información digital necesaria en
una determinada computación [...] sino también
las instrucciones que gobiernen la rutina a rea-
lizar sobre los datos numéricos. En una máquina
de propósito especial, estas instrucciones son un
componente integrante del dispositivo y constitu-
yen parte de su estructura de diseño. Para que la
máquina sea de propósito general, debe ser po-
sible instruirla de modo que pueda llevar a ca-
bo cualquier computación formulada en términos
numéricos. Por tanto, debe existir algún órgano
capaz de almacenar esas órdenes de programa...»
En el escrito se utilizan indistintamente, y con
el mismo significado, «instrucciones», «órdenes»
y «órdenes de programa». Actualmente se habla
siempre de instrucciones. El conjunto de instruc-
ciones diferentes que puede ejecutar un ordenador
se llama juego o repertorio de instrucciones.
0.8 Un último ejemplo: la «máquina de von Neumann»
Esbozado el modelo estructural en el nivel de
máquina convencional, es preciso describir sus
subsistemas mediante modelos funcionales.
Memoria
«... Hemos diferenciado, conceptualmente, dos
formas diferentes de memoria: almacenamiento
de datos y almacenamiento de órdenes. No obs-
tante, si las órdenes dadas a la máquina se redu-
cen a un código numérico, y si la máquina puede
distinguir de alguna manera un número de una
orden, el órgano de memoria puede utilizarse pa-
ra almacenar tanto números como órdenes.»
Es decir, en el subsistema de memoria se alma-
cenan tanto las instrucciones que forman un pro-
grama como los datos. Esto es lo que luego se ha
llamado «arquitectura Princeton» (como veremos
en el Apartado 15.7, en ciertos diseños se utiliza
una memoria para datos y otra para instrucciones,
siguiendo una «arquitectura Harvard»).
«... Planeamos una facilidad de almacena-
miento electrónico completamente automático de
unos 4.000 números de cuarenta dígitos binarios
cada uno. Esto corresponde a una precisión de
2−40 ≈ 0, 9 × 10−12 , es decir, unos doce decima-
les. Creemos que esta capacidad es superior en
un factor de diez a la requerida para la mayoría
de los problemas que abordamos actualmente...
Proponemos además una memoria subsidiaria de
mucha mayor capacidad, también automática, en
algún medio como cinta o hilo magnético.»
La capacidad planeada, expresada en unidades
actuales, era 4.000 × 40/8 = 20.000 bytes, es de-
cir, menos de 2 KB. Obviamente, los problemas
a los que se dirigía esa máquina no eran los que
hoy resuelven los ordenadores... Se habla de una
memoria secundaria. En este libro no la contem-
plaremos hasta la Lección 5.
«... Lo ideal sería... que cualquier conjunto de
cuarenta dígitos binarios, o palabra, fuese accesi-
ble inmediatamente —es decir, en un tiempo con-
siderablemente inferior al tiempo de operación
de un multiplicador electrónico rápido—[...] De
29
aquí que el tiempo de disponibilidad de una pa-
labra de la memoria debería ser de 5 a 50 µseg.
Asimismo, sería deseable que las palabras pudie-
sen ser sustituidas por otras nuevas a la misma
velocidad aproximadamente. No parece que fí-
sicamente sea posible lograr tal capacidad. Por
tanto, nos vemos obligados a reconocer la posi-
bilidad de construir una jerarquía de memorias,
en la que cada una de las memorias tenga una
mayor capacidad que la precedente pero menor
rapidez de acceso...»
La velocidad también se ha multiplicado por va-
rios órdenes de magnitud: el tiempo de acceso en
las memorias de semiconductores (con capacida-
des de millones de bytes), es alrededor de una mi-
lésima parte de esos 5 a 50 µs que «no parece que
sea posible lograr».
Aquí aparece una característica esencial de la
memoria principal: la de ser de acceso directo,
también llamado acceso aleatorio («sería desea-
ble que las palabras pudiesen ser sustituidas por
otras nuevas a la misma velocidad»), así como el
concepto de jerarquía de memorias, ampliamen-
te desarrollado después, y que estudiaremos en la
Lección 15. De momento sólo consideraremos la
existencia de una única memoria, de acceso direc-
to y de lectura y escritura, y nos referiremos a ella
como «memoria» o como «MP», indistintamente .
El elemento mínimo de almacenamiento es el
bit. Un punto de memoria es un mecanismo físi-
co capaz de almacenar un bit. En la MP, estos pun-
tos de memoria (formados por circuitos con tran-
sistores) se agrupan en «posiciones», «celdas» o
«casillas», en cada una de las cuales se aloja un
conjunto de bits, llamado palabra. En cada acce-
so (de escritura, o grabación en la memoria, o de
lectura, o recuperación de la memoria) se intro-
duce o se extrae una palabra completa (n bits; va-
lores típicos de n son 8, 16, 32 o 64, dependiendo
del ordenador). Cada una de estas posiciones vie-
ne identificada por una dirección, número entero
comprendido entre 0 y M–1, donde M es la capa-
cidad de la memoria: el número de posiciones, es
decir, de palabras que puede almacenar.
30
Como ilustra la Figura 0.24, para extraer una pa-
labra de la memoria (operación de lectura) se da
su dirección y, tras un tiempo de acceso para la
lectura, se tiene en la salida el contenido de esa
posición. Para introducir una palabra en una posi-
ción (operación de escritura), se indica también
la dirección y, tras un tiempo de acceso para la es-
critura, queda la palabra grabada. Decir que la me-
moria tiene acceso directo, o aleatorio, significa
simplemente que el tiempo que transcurre desde
que a la memoria se le da una microorden de lectu-
ra o escritura hasta que la operación ha concluido
es independiente de la posición (véase el Aparta-
do 4.12).
microórdenes de la UC:
lec esc
dirección posición direccionada (n bits)
palabra palabra
obtenida a grabar
(caso de lectura) (caso de escritura)
Figura 0.24. Lectura y escritura en una memoria de
acceso aleatorio.
Dos propiedades importantes de la MP son:
• Una celda nunca puede estar «vacía»: siempre
tiene un contenido formado por un conjunto de
bits («ceros» y «unos»).
• La operación de lectura no es «destructiva»: el
contenido leído permanece tal como estaba pre-
viamente en la celda; la escritura sí lo es: el
contenido anterior desaparece y queda sustitui-
do por el nuevo.
El término palabra se refiere, de forma abstrac-
ta, a un conjunto (ordenado, es decir, una «lista»)
de bits. Pero lo utilizaremos indistintamente para
referirnos tanto a una posición de la MP como a su
contenido.
Lección 0. Modelos y niveles
Unidad aritmética y lógica
«... Puesto que el dispositivo va a ser una má-
quina computadora, ha de contener un órgano
aritmético que pueda realizar ciertas operacio-
nes aritméticas elementales. Por tanto, habrá una
unidad capaz de sumar, restar, multiplicar y divi-
dir...»
«... Las operaciones que la máquina consi-
derará como elementales serán, evidentemente,
aquellas que se le hayan cableado. Por ejemplo,
la operación de multiplicación podrá eliminarse
del dispositivo como proceso elemental si la con-
sideramos como una sucesión de sumas correcta-
mente ordenada. Similares observaciones se pue-
den aplicar a la división. En general, la economía
de la unidad aritmética queda determinada por
una solución equilibrada entre el deseo de que la
máquina sea rápida — una operación no elemen-
tal tardará normalmente mucho tiempo en ejecu-
tarse, al estar formada por una serie de órdenes
dadas por el control — y el deseo de hacer una
máquina sencilla, o de reducir su coste...»
Como su nombre indica, la UAL incluye tam-
bién las operaciones de tipo lógico (negación,
o «NOT», conjunción, o «AND», disyunción, u
«OR»), que no se mencionan aquí, pero sí en otras
partes del documento que estamos comentando.
Al final de la cita aparece claramente expresado
un ejemplo del problema de la disyuntiva hardwa-
re/software, habitual en el diseño de los ordena-
dores, y que veremos repetirse a lo largo de todo
el curso: muchas funciones pueden realizarse in-
distintamente de manera cableada (por hardware)
o de manera programada (por software). La elec-
ción depende de que predomine el deseo de redu-
cir el coste (soluciones software) o de conseguir
una máquina más rápida (soluciones hardware).
En la Segunda Parte estudiaremos una solución in-
termedia: la realización microprogramada (o por
firmware).
En resumen, la unidad aritmética y lógica, o
UAL, es un subsistema que puede tomar dos ope-
randos (o sólo uno, como en el caso de «NOT»)
y generar el resultado correspondiente a la ope-
ración que se le indique, de entre un conjunto de
0.8 Un último ejemplo: la «máquina de von Neumann»
operaciones previstas en su diseño. En lo sucesivo
seguiremos el convenio de representar la UAL por
el diagrama de la Figura 0.25.
resultado
operación 1
operación 2
UAL ...
operación n
operando 1 operando 2
Figura 0.25 Diagrama de la UAL.
«... Al considerar los órganos de cálculo de
una máquina computadora nos vemos natural-
mente obligados a pensar en el sistema de nume-
ración que debemos adoptar. Pese a la tradición
establecida de construir máquinas digitales con
el sistema decimal, para la nuestra nos sentimos
más inclinados por el sistema binario...»
Luego de unas consideraciones para justificar
esta elección, muy ligadas a la tecnología de la
época (aunque podrían aplicarse también, en esen-
cia, a la tecnología actual), continúa con las venta-
jas del sistema binario:
«... La principal virtud del sistema binario
frente al decimal radica en la mayor sencillez y
velocidad con que pueden realizarse las opera-
ciones elementales...»
«... Un punto adicional que merece resaltarse
es éste: una parte importante de la máquina no
es de naturaleza aritmética, sino lógica. Ahora
bien, la lógica, al ser un sistema del sí y del no, es
fundamentalmente binaria. Por tanto, una dispo-
sición binaria de los órganos aritméticos contri-
buye de manera importante a conseguir una má-
quina más homogénea, que puede integrarse me-
jor y ser más eficiente...»
«... El único inconveniente del sistema binario
desde el punto de vista humano es el problema
de la conversión. Sin embargo, como se cono-
ce perfectamente la manera de convertir núme-
ros de una base a otra, y puesto que esta con-
versión puede efectuarse totalmente mediante la
31
utilización de los procesos aritméticos habituales,
no hay ninguna razón para que el mismo compu-
tador no pueda llevar a cabo tal conversión. Po-
dría argumentarse que ésta es una operación que
consume mucho tiempo. Sin embargo, no es así
[...]. Está claro que un computador de propósito
general, utilizado como herramienta de investiga-
ción científica, está llamado a hacer gran número
de multiplicaciones sobre una cantidad relativa-
mente pequeña de datos de entrada, y de aquí que
el tiempo consumido en la conversión de decimal
a binario sea solamente un pequeño porcentaje
del tiempo total de computación. Una observa-
ción similar cabe aplicar a los datos de salida...»
La propuesta era para una máquina que, aunque
«de propósito general», estaba concebida pensan-
do especialmente en su aplicación a problemas de
cálculo científico. Cuando más tarde aparecieron
las primeras aplicaciones comerciales, se vio que
podía ser más eficiente hacer las operaciones arit-
méticas en decimal (aunque, desde luego, codifi-
cando los dígitos decimales en binario, es decir,
utilizando códigos BCD, como veremos en la Lec-
ción 3).
Unidades de entrada y salida
«... Por último, tiene que haber dispositivos,
que constituyen el órgano de entrada y de sali-
da, mediante los cuales el operador y la máqui-
na puedan comunicarse entre sí [...] Este órgano
puede considerarse como una forma secundaria
de memoria automática...»
Las unidades de entrada y salida, o dispositivos
periféricos (que, abreviadamente, se suelen llamar
o bien dispositivos o bien periféricos), represen-
tadas en la Figura 0.23 como un simple bloque
(UE/S), pueden ser muchas y variadas. Se inclu-
yen entre ellas no sólo las que permiten la comu-
nicación con las personas (teclado, pantalla, ratón,
impresora, etc.), sino también las memorias secun-
darias (cintas, discos, etc.), como veremos en la
Lección 5.
32
Unidad de control
«... Si la memoria para órdenes es simplemente
un órgano de almacenamiento, tiene que haber
otro órgano que pueda ejecutar automáticamente
las órdenes almacenadas en la memoria. A este
órgano le llamaremos el control ...»
La UC examina las instrucciones («órdenes»)
almacenadas en la memoria y genera las seña-
les («microórdenes»)38 precisas para que las otras
unidades ejecuten lo que indica la instrucción.
microórdenes dirección de dato dirección de la
(a la UAL, la MP (a la MP instrucción
y/o las UE/S) o las UE/S) siguiente (a la MP)
UC
instrucción (de la MP)
Figura 0.26 Unidad de control.
«... Tiene que ser posible extraer números de
cualquier parte de la memoria en cualquier mo-
mento. Sin embargo, en el caso de las órdenes, el
tratamiento puede ser más metódico, puesto que
las instrucciones de control se pueden poner, por
lo menos parcialmente, en secuencia lineal. En
consecuencia, el control se construirá de forma
que normalmente proceda de la posición n de me-
moria a la posición (n+1) para su siguiente ins-
trucción...»
Tras la ejecución de una instrucción que está al-
macenada en la palabra de dirección d de la me-
moria, la siguiente a ejecutar es, normalmente, la
almacenada en la dirección d + 1 (las excepciones
son las instrucciones de bifurcación, que comenta-
remos luego, al hablar de los programas).
38
Cómo la unidad de control genera estas microórdenes es
ya algo propio del nivel de microarquitectura, a lo que dedi-
caremos la Segunda Parte.
Lección 0. Modelos y niveles
«... Debe ser posible transferir datos de la me-
moria al órgano aritmético, y viceversa. En la
transferencia de la información desde el órgano
aritmético a la memoria hay que distinguir dos
tipos: transferencias de números como tales y
transferencias de números que forman parte de
órdenes. El primer caso es bastante obvio y no
necesita mayor explicación. El segundo es más
sutil y sirve para explicar la generalidad y sen-
cillez del sistema. Consideremos, a modo de ilus-
tración, el problema de la interpolación. Supon-
gamos que hemos formulado las instrucciones ne-
cesarias para realizar una interpolación de orden
n en una secuencia de datos. La posición exacta
dentro de la memoria de las (n+1) cantidades que
pueden corresponder al valor funcional deseado
es función de un argumento. Y este argumento es,
probablemente, el resultado de una computación
en la máquina. Así pues, necesitamos una orden
que pueda sustituir un número dentro de una de-
terminada orden — en el caso de la interpolación,
la posición del argumento o del grupo de argu-
mentos más próximo en nuestra tabla al valor de-
seado —. Por medio de tal orden, los resultados
de un cálculo se pueden introducir en las instruc-
ciones que realizan esa u otra computación dife-
rente. Esto hace posible que una secuencia de ins-
trucciones se pueda utilizar con diferentes con-
juntos de números localizados en diferentes par-
tes de la memoria...»
«... En resumen, las transferencias a la memo-
ria serán de dos tipos: sustituciones totales, con
las que la cantidad previamente almacenada que-
da borrada y sustituida por un nuevo número, y
sustituciones parciales con las que la parte de una
orden que contiene un número de posición de me-
moria — suponemos que las distintas posiciones
de memoria están numeradas consecutivamente
por números de posición de memoria — queda
sustituida por un nuevo número de posición de
memoria...»
Estos dos párrafos aluden a una técnica a la que
había que recurrir en las primeras máquinas para
recorrer zonas de memoria: la modificación de ins-
trucciones. Posteriormente se introdujeron otros
mecanismos, que estudiaremos a partir de la Lec-
ción 2, con los que se resuelve el mismo problema
de forma más segura y cómoda, pero la posibili-
0.8 Un último ejemplo: la «máquina de von Neumann»
dad de modificar las instrucciones en el curso de
la ejecución de un programa es consecuencia de
la misma idea de programa almacenado, y, desde
el punto de vista didáctico, ayuda a comprender el
funcionamiento del ordenador. Analizaremos ca-
sos concretos en la Lección siguiente.
Los «números de posiciones de memoria» son
las direcciones, definidas más arriba al hablar de
la memoria.
Formato de instrucciones
Hasta aquí se han presentado el modelo estruc-
tural en el nivel de máquina convencional y los
modelos funcionales de sus componentes. El mo-
delo funcional de la unidad de control, descrito de
manera muy simplificada, es también un modelo
procesal de la máquina completa.
Ahora pasamos al modelo funcional, es decir, a
lo que es necesario conocer para usar (programar)
la máquina.
«... Como la memoria va a tener 212 = 4.096
palabras de cuarenta dígitos [...] un número bina-
rio de doce dígitos es suficiente para identificar a
una posición de palabra...»
«... Dado que la mayoría de las operaciones
del computador hacen referencia al menos a un
número en una posición de la memoria, es razo-
nable adoptar un código en el que doce dígitos
binarios de cada orden se asignan a la especifi-
cación de una posición de memoria. En aquellas
órdenes que no precisan extraer o introducir un
número en la memoria, esas posiciones de dígitos
no se tendrán en cuenta...»
«... Aunque aún no está definitivamente deci-
dido cuántas operaciones se incorporarán en el
computador (es decir, cuántas órdenes diferentes
debe ser capaz de comprender el control), con-
sideraremos por ahora que probablemente serán
más de 25 , pero menos de 26 . Por esta razón, es
factible asignar seis dígitos binarios para el có-
digo de orden. Resulta así que cada orden de-
be contener dieciocho dígitos binarios, los doce
primeros para identificar una posición de memo-
ria y los seis restantes para especificar una ope-
ración. Ahora podemos explicar por qué las ór-
33
denes se almacenan en la memoria por parejas.
Como en este computador se va a utilizar el mis-
mo órgano de memoria para órdenes y para nú-
meros, es conveniente que ambos tengan la mis-
ma longitud. Pero números de dieciocho dígitos
binarios no serían suficientemente precisos para
los problemas que esta máquina ha de resolver.
Se requiere más bien una precisión de al menos
10−10 , o 2−33 . De aquí que sea preferible hacer
las palabras suficientemente largas para acomo-
dar dos órdenes...»
«... Nuestros números van a tener cuarenta dí-
gitos binarios cada uno. Esto permite que cada
orden tenga veinte dígitos binarios: los doce que
especifican una posición de memoria y ocho más
que especifican una operación (en lugar del mí-
nimo de seis a que nos referíamos más arriba)...»
O sea, el formato de instrucciones propuesto es
el que indica la Figura 0.27, con dos instrucciones
en cada palabra. En muchos diseños posteriores
se ha seguido más bien la opción contraria: pala-
bras relativamente cortas e instrucciones que pue-
den ocupar una o más palabras, y lo mismo para
los números39 .
8 12 8 12
CO CD CO CD
Figura 0.27. Formato de instrucciones de la «máquina
de von Neumann».
En general, un formato es la definición del sig-
nificado de cada uno de los bits de una palabra. Se
representa gráficamente como un rectángulo que
«cubre» todos los bits. En un formato se distin-
guen partes o campos, grupos de bits con signifi-
cado propio.
En el formato de la Figura 0.27 hay dos campos
para cada una de las instrucciones: uno de ocho
bits, «CO», que indica de qué instrucción se tra-
ta (el código de operación), y otro de doce bits,
CD, que da la dirección de la MP a la que hace
referencia la instrucción.
39
Una excepción son los llamados «VLIWC» (Very Large
Instruction Word Computers, Apartado 15.3.
34
Programas
«... La utilidad de un computador automáti-
co radica en la posibilidad de utilizar repetida-
mente una secuencia determinada de instruccio-
nes, siendo el número de veces que se repite o
bien previamente determinado o bien dependien-
te de los resultados de la computación. Cuando
se completa cada repetición hay que seguir una u
otra secuencia de órdenes, por lo que en la ma-
yoría de los casos tenemos que especificar dos se-
cuencias distintas de órdenes, precedidas por una
instrucción que indique la secuencia a seguir. Es-
ta elección puede depender del signo de un núme-
ro (el cero representará “positivo” a efectos in-
ternos en la máquina). En consecuencia, introdu-
cimos una orden (la orden de transferencia con-
dicionada) que, dependiendo del signo de un nú-
mero determinado, hará que se ejecute la rutina
apropiada de entre las dos...»
«... Frecuentemente, dos secuencias distintas
de órdenes terminan en una rutina común. Por
tanto, es preciso indicar al control que en ambos
casos siga desde el punto de comienzo de la ruti-
na común. Esta transferencia incondicionada pue-
de llevarse a cabo bien por el empleo artificial de
una transferencia condicionada o bien mediante
la introducción de una orden explícita para tal
transferencia...»
Es decir, los programas constan de una secuen-
cia de instrucciones que se almacenan consecuti-
vamente en la memoria. Normalmente, tras la eje-
cución de una instrucción se pasa a la siguiente.
Pero en ocasiones hay que pasar no a la instrucción
almacenada en la dirección siguiente, sino a otra,
almacenada en otra dirección. Para poder hacer tal
cosa están las instrucciones de transferencia de
control, o instrucciones de bifurcación40 .
Para completar el modelo funcional sería preci-
so especificar todas las instrucciones, explicando
para cada una su código de operación y lo que hace
la instrucción. Esto es lo que haremos en la Lec-
ción 1, con una máquina muy similar a la descrita
en este documento que hemos comentado.
40
Como veremos en la Lección 4, las instrucciones de bi-
furcación son un caso particular de las de transferencia de
control.
Lección 0. Modelos y niveles
0.9. Estructura y contenido del libro
Este libro se centra en los niveles superiores al
de circuito lógico. La Primera Parte se dedica al
nivel de máquina convencional, la Segunda al de
microarquitectura, y la Tercera al de máquina ope-
rativa, con algunos ingredientes del nivel de má-
quina simbólica.
Se añaden tres Apéndices. El primero resume
algunos elementos sobre codificación, sistemas de
numeración y aritmética binaria, necesarios para
la Lección 3. El segundo recoge los conceptos bá-
sicos (necesarios para la Segunda Parte) sobre el
nivel de circuito lógico. Y en el tercero se presen-
tan alfabéticamente las traducciones de términos
ingleses comentadas en los Apartados de «Obser-
vaciones terminológicas».
Cada Parte consta de ocho Lecciones en las que
se desarrollan modelos funcionales, estructurales
y procesales en el nivel correspondiente. Estos
modelos se particularizan dando lugar a una gran
diversidad de detalles cuando se aplican a orde-
nadores reales. Nuestro enfoque es conceptual: se
trata de formar conceptos básicos y generales que
el lector pueda posteriormente aplicar a máquinas
concretas con las que tenga que trabajar. Por eso,
no describimos ningún ordenador real (salvo algu-
nos detalles, en algunos de los Ejercicios).
Ahora bien, los conceptos y los modelos gene-
rales sólo se asientan bien mentalmente si se con-
cretan con estudios de casos. Definiremos para es-
to máquinas ficticias especialmente pensadas para
concentrarse en lo esencial y no perderse en los
detalles de las máquinas reales. Con «Símplez»
y «Símplez+i4», las más elementales, introducire-
mos lo más básico. «Algorítmez», algo más ela-
borada, nos permitirá presentar muchas de las ca-
racterísticas que se encuentran en la realidad, en
el nivel de máquina convencional y en el de mi-
cromáquina; asimismo, se utilizará, en la Tercera
Parte, para entrar en el nivel de máquina operativa.
Finalmente, «Regístrez» incluye ya prácticamente
todos los mecanismos de una arquitectura y una
microarquitectura reales.
0.9 Estructura y contenido del libro 35

NIVELES DE MAQUINA
OPERATIVA/SIMBOLICA

17 21 22 23 24
Monoalgorítmez y
Multialgorítmez

18 19 20 Conocimientos
Conocimientos de Java
básicos

NIVEL DE MAQUINA
CONVENCIONAL Conocimientos
avanzados
3 4 5
Símplez Algorítmez Regístrez
Conocimientos
1 2 básicos 6 7 8

NIVEL DE MICROARQUITECTURA

12 15
Símplez Algorítmez Regístrez

9 10 11 13 14 16
Conocimientos Conocimientos
básicos avanzados

Figura 0.28 Diagrama de dependencias entre las Lecciones.

En cada Parte se encuentran dos tipos de Lec-
ciones: las que se apoyan en las máquinas ficticias
para introducir conceptos o para concretarlos, y las
que presentan modelos más generales y variacio-
nes, generalizando los detalles de las otras Leccio-
nes. Así, en las dos primeras Partes se empieza con
el caso concreto de Símplez, luego se generaliza y
finalmente se vuelven a concretar algunos detalles
con Algorítmez y con Regístrez. La Tercera Par-
te comienza con una Lección general a la que si-
guen tres en las que se desarrollan modelos de sis-
temas operativos para Algorítmez, otra de carácter
general sobre el nivel de máquina simbólica, y, fi-
nalmente, dos Lecciones sobre la Máquina Virtual
Java cuya lectura requiere conocer el lenguaje de
programación Java.
Las Lecciones están secuenciadas, como es ha-
bitual, para un estudio lineal del libro. Pero se
puede navegar por ellas de otras maneras, depen-
diendo de los intereses del lector y de sus cono-
cimientos previos. La Figura 0.28 resume las de-
pendencias más importantes entre las Lecciones
y puede servir de orientación, junto con la Tabla
de materias, para establecer posibles trayectorias.
Las flechas de trazo continuo indican dependen-
cias «fuertes», en el sentido de que la Lección en la
que entra una de estas flechas es muy dependiente
de lo tratado en aquella de la que procede. Las de
puntos son «débiles»: la Lección puede asimilarse
sin necesidad de haber estudiado la precedente, si
bien habrá que acudir a ella en algunos momen-
tos (estas referencias concretas se explicitan en el
texto de cada Lección, en los lugares oportunos).
También es posible, si se dispone de conoci-
mientos previos, empezar el estudio en lugares in-
termedios. Los «conocimientos básicos» a los que
alude la Figura 0.28 se refieren a:
• En los niveles de máquina operativa y máquina
simbólica (entrada a la Lección 17), estructura y
funcionamiento en el nivel de máquina convencio-
nal. (Pero obsérvese que las Lecciones 18 y 19 se
sustentan en el caso concreto de Algorítmez, y re-
quieren el conocimiento previo de algunos detalles
de las Lecciones 6 y 7).
• En el nivel de máquina convencional (entrada a
36
la Lección 3), ideas básicas de la «arquitectura de
von Neumann» y de programación en ese nivel.
• En el nivel de microarquitectura (entrada a la
Lección 12), conceptos de transferencias entre re-
gistros y control. (Pero obsérvese también que las
Lecciones 13 y 14 son dependientes de la 6).
Las dos Lecciones sobre Regístrez (8 y 16) pue-
den estudiarse con bastante independencia de las
demás si se dispone de una buena base de conoci-
mientos sobre los niveles de máquina convencio-
nal y microarquitectura.
Como ejemplos de adaptación del material a di-
ferentes necesidades, lo hemos utilizado en:
• Un curso básico sobre estructura y funciona-
miento de los ordenadores impartido dentro de un
programa de reconversión de titulados superiores a
las tecnologías de la información. Un curso sobre
programación (con Pascal) y otro sobre circuitos
lógicos precedían a éste. El objetivo era impartir
conocimientos imprescindibles a futuros usuarios
de los niveles de máquina convencional, máquina
operativa y/o máquina simbólica. Para un total de
sesenta horas lectivas, se siguieron las Lecciones
1, 2, 3, 4, 9, 10, 11, 17, 21 y 22.
• La asignatura «Fundamentos de Ordenadores»,
incluida en el segundo curso del plan de estudios
de la Escuela Técnica Superior de Ingenieros de
Telecomunicación de Madrid. Es una asignatura
cuatrimestral de seis créditos cuyos alumnos han
estudiado previamente programación (con Java) y
electrónica digital. El contenido de «Fundamentos
de ordenadores» (que se amplía en «Arquitectura
de ordenadores») junto con el de «Fundamentos
de programación», es el pilar básico para varias
de las asignaturas incluidas en la especialidad de
Telemática: «Ingeniería del software», «Softwa-
re de comunicaciones», «Sistemas operativos dis-
tribuidos», «Bases de datos», etc. En los últimos
años hemos seguido, esencialmente, la siguiente
secuencia de Lecciones: 1, 2, 9, 10, 11 (Símplez),
3, 4 (variaciones), 6, 7 (Algorítmez), 12 y 15 (mi-
cromáquina y microarquitectura). Esto representa,
aproximadamente, el 40 % del texto.
Lección 0. Modelos y niveles
• Introducción a los sistemas operativos en
la asignatura «Arquitectura de ordenadores», de
cuarto curso, con las Lecciones 18 a 20 (Mono-
algorítmez y Multialgorítmez).
0.10. Resumen
Los ordenadores son sistemas complejos que
pueden estudiarse, diseñarse o utilizarse desde dis-
tintos puntos de vista. Estos puntos de vista pue-
den situarse en una jerarquía de niveles de abstrac-
ción. Los niveles de esta jerarquía aparecen en la
Figura 0.22. Y dentro de cada nivel se puede des-
cribir la función (mediante un modelo funcional),
la estructura (mediante un modelo estructural) o el
funcionamiento (mediante un modelo procesal).
En las descripciones de ordenadores se utilizan
frecuentemente los tres modelos, como hemos po-
dido ver al comentar la descripción clásica de la
«máquina de von Neumann».
Una vez fijado este marco conceptual, se pue-
de situar en él el contenido del libro. Es lo que se
resume en la Figura 0.28.
Terminaremos con una reflexión acerca de la se-
cuencia de estudio de los modelos en distintos ni-
veles. Podría pensarse en recorrer la jerarquía or-
denadamente, en sentido ascendente o descenden-
te, de manera indiferente. En efecto, en principio
cada nivel debería poder estudiarse independien-
temente de los demás: basta con conocer los mo-
delos funcionales del nivel inmediatamente infe-
rior. Aquí, sin embargo, empezamos en el nivel de
máquina convencional, luego «descendemos» al
de microarquitectura y finalmente «nos elevamos»
a los de máquina operativa y máquina simbólica.
Las flechas de la Figura 0.28 sugieren esta trayec-
toria, que tiene una justificación: las ideas básicas
de los modelos funcional, estructural y procesal en
el nivel de máquina convencional propuestos por
von Neumann aún se conservan, a pesar de la gran
evolución tecnológica posterior, y su fuerza es tal
que determinan de manera fundamental la mayo-
ría de los modelos en los otros niveles.
0.11 Observaciones terminológicas
0.11. Observaciones terminológicas
A lo largo del libro aparece con frecuencia el tér-
mino genérico «máquina» para designar a un tipo par-
ticular de máquina, el ordenador. No es más que una
sinécdoque para eludir la reiteración.
Muchos autores de lengua castellana rechazan la de-
nominación «ordenador», y hablan de «computador»
o «computadora». Éstos son, además, los términos
utilizados habitualmente en los países americanos de
habla española. «Ordenador» tiene origen francés: lo
introdujo Jacques Perret con motivo de la presentación
en Europa del IBM 701 (Elgozy, 1970)41 .
Según Edgar Morin (1977), «[...] el término francés
‘ordinateur’—que expresa tanto la emisión de órdenes
como la puesta en orden—completa el término anglo-
sajón ‘computer’, que expresa el tratamiento de la in-
formación. Se trata de un aparato de mando». Podemos
añadir que «computador» evoca las aplicaciones exclu-
sivamente numéricas para las que se diseñaron los pri-
meros ordenadores, mientras que actualmente, y cada
vez más, la mayor parte del procesamiento que se rea-
liza con ordenadores es de naturaleza simbólica.
Hemos procurado buscar las traducciones más idó-
neas para los términos técnicos. Entre las excepciones
(palabras que dejamos en inglés para no perturbar la
comprensión) están «hardware» (para el conjunto de
componentes físicos que constituyen el ordenador) y
«software» (para los programas), que son los únicos
utilizados en el mundo profesional y hasta en la cultura
popular. Se han propuesto traducciones, como «mate-
rial» y «logical» (influidas por las francesas «materiel»
y «logiciel»), «soporte físico» y «soporte lógico», pero
su aceptación ha sido escasa.
«Implementar» es, según el D.R.A.E., «poner en
funcionamiento, aplicar métodos, medidas, etc., para
llevar algo a cabo». Como hemos podido ver en esta
Lección, el término adquiere un significado específi-
co en el contexto de la jerarquía de niveles de abstrac-
ción: en cada nivel, implementar es concretar estructu-
ralmente, mediante componentes del nivel inferior, un
sistema descrito funcionalmente.
«Procesal» no es un adjetivo que se utilice habitual-
mente en el campo de los ordenadores, donde general-
mente se habla de «descripción del comportamiento»
41
De ahora en adelante las referencias a las fuentes apare-
cen con el nombre del autor y el año. Los datos completos, or-
denados alfabéticamente por autores, están en «Referencias»,
al final del libro.
37
o de «funcionamiento» para referirse a lo que nosotros
llamamos «modelo procesal». La adecuación del tér-
mino al concepto parece clara: «procesal» es «pertene-
ciente o relativo al proceso».
Algunos de los nombres de los niveles de máqui-
nas requieren comentario. «Nivel de máquina conven-
cional» es una expresión introducida por Tanenbaum
en un texto clásico que referenciamos más adelante. El
prefijo «micro» en el «nivel de micromáquina» («nivel
de microprogramación», según Tanenbaum) sólo se re-
fiere a un mayor grado de resolución, o de detalle, que
el propio del nivel de máquina convencional; es decir,
no guarda relación alguna con el tamaño físico de la
máquina (Apartado 9.1). El «nivel de máquina operati-
va» es el que corresponde a una máquina acompañada
de unos programas que constituyen lo que se llama un
«sistema operativo». Cabe discutir si «sistema operati-
vo» es una traducción acertada de operating system42 ,
pero es la utilizada por todos los hispanohablantes (y
consagrada por la R.A.E.). Finalmente, el «nivel de má-
quina simbólica» implica que la máquina procesa sím-
bolos o, lo que es igual, el lenguaje que corresponde a
la máquina está definido sobre un alfabeto de símbolos
más rico que «{0,1}» (véase el Apartado 17.6).
En las descripciones de los años 40 y 50 se utiliza-
ba la palabra «orden» como sinónimo de «instrucción».
Por eso, se llamaron «microórdenes» a las señales ge-
neradas por la UC para gobernar a las otras unidades, y
esta denominación sí se ha conservado, diferenciándo-
la de «microinstrucción», como veremos en la Segun-
da Parte. Asimismo, se hablaba de «dígito binario»; el
término «bit», como contracción de «binary digit», lo
propuso John Tukey en 1949 (frente a otras alternati-
vas que también se contemplaron: «bigit», «binit»...)
(Howe, 2004).
En muchos textos y manuales escritos en español se
utilizan las abreviaturas CPU (por «Central Processing
Unit»), ALU (por «Arithmetic and Logic Unit») y MM
(por «Main Memory») en lugar de UCP, UAL y MP,
respectivamente.
El D.R.A.E. dice que un «chip» es un «pequeño cir-
cuito integrado que realiza numerosas funciones en or-
denadores y dispositivos electrónicos», y para «proce-
sador» da una definición aún más sorprendente: «uni-
42
A «operativo» («dícese de lo que obra y hace su efec-
to») le corresponde en inglés «operative». El verbo «operate»
debería traducirse por «hacer funcionar» o «explotar». Hace
años se decía «sistema de explotación» (y su equivalente en
francés sí se ha conservado).
38
dad central de proceso, formada por uno o dos chips».
(Una UCP puede implementarse con uno, con dos, o
con cualquier número de chips).
La definición «clásica» de palabra (en tecnología
de ordenadores) es conjunto de bits que se transfieren
en paralelo entre la MP y la UCP. No obstante, la evo-
lución tecnológica ha hecho que esta definición tenga
que matizarse. En efecto, actualmente es frecuente que
la MP esté organizada por «octetos» o «bytes»43 (cada
dirección identifica a un conjunto de ocho bits) y que
en una operación de lectura o escritura se recupere o
grabe una de esas «palabras» de ocho bits. Las instruc-
ciones y los datos suelen ocupar varios bytes, lo cual,
en principio, implicaría que para grabarlos o recupe-
rarlos hubiera que hacer varios accesos de escritura o
lectura a la memoria. Así, en efecto, funcionan muchos
sistemas basados en microprocesador y, concretamen-
te, el primitivo «PC» (Personal Computer) de hace unos
años, que tienen un «bus de datos» de ocho bits; en
ellos puede decirse que la longitud de palabra es ocho
bits. Pero para reducir el número de accesos a la MP (y,
de este modo, aumentar la velocidad del ordenador) lo
más frecuente es que la MP esté organizada de tal mo-
do que se puedan leer en un solo acceso conjuntos de
ocho, de dieciséis, o de treinta y dos bits. Así funcio-
nan los actuales pecés, en los que el bus de datos y la
longitud de palabra tienen dieciséis o treinta y dos bits.
Por ejemplo, en un ordenador de treinta y dos bits los
accesos a la MP pueden ser a «octeto» («byte», ocho
bits), a «media palabra» («half word», dos bytes) o a
«palabra» («word», cuatro bytes).
0.12. Notas históricas
No es fácil sintetizar la historia de los instrumentos
de cálculo y su evolución hasta el ordenador, porque,
como dice Smith (1970),
«...en realidad, el pasado es reticulado y no li-
neal. Es una malla de acontecimientos entrete-
jidos e interrelacionados de forma complicada,
inesperada y no siempre racional. En consecuen-
cia, el fenómeno histórico de “convergencia” es
mucho más significativo que la simplista cuestión
escolar de quién inventó el ordenador o quién
construyó el primer contador dentado».
Vamos a señalar aquí algunos hitos significativos
hasta la llamada «primera generación de ordenadores».
43
En lo sucesivo diremos siempre «bytes» (Apartado 3.10).
Lección 0. Modelos y niveles
En Lecciones sucesivas, conforme vayamos estudiando
la evolución de «máquina de von Neumann», iremos
indicando el origen de las aportaciones posteriores.
Los precursores
Es preciso retroceder miles de años para encontrar
los ábacos como primitivas herramientas de cálculo.
Se ha dicho que el primer computador fue el «meca-
nismo de Antikythera», sistema mecánico para cálcu-
los de astronomía diseñado en Grecia hace unos dos
mil años (Morris, 1984). Pero es mucho más conoci-
do que Pascal construyó en 1642 una calculadora basa-
da en ruedas-contadoras dentadas; Leibniz, en 1671, la
perfeccionó, añadiéndole las operaciones de multipli-
cación y división, aunque su comercialización tuvo que
esperar (por motivos tecnológicos) hasta bien entrado
el siglo XIX, extendiéndose su uso desde entonces y
hasta muy recientemente, cuando la tecnología electró-
nica terminó por sustituir a la mecánica.
Suele mencionarse como uno de los precursores más
importantes a Charles Babbage, que desde 1832 has-
ta su fallecimiento en 1871 trabajó en el diseño de su
«máquina analítica», primer modelo de computador au-
tomático de uso general, en el que se encuentra ya la
especialización de unidades funcionales: memoria, uni-
dad aritmética, control y entrada/salida. Sus contempo-
ráneos consideraron el invento como producto de una
mente febril (y no les faltaba algo de razón: la máquina
era prácticamente irrealizable con la tecnología de la
época). Asombra hoy su capacidad para alumbrar ideas
que habrían de esperar casi un siglo para ser llevadas
a la práctica (concepto de programa, de bucle, etc.). El
libro de Morrison y Morrison (1961) está integramente
dedicado a las máquinas de Babbage.
Babbage pensó en las tarjetas perforadas (inventa-
das por Jacquard para los telares) como soporte para
almacenamiento de programas y datos. Poco después,
en Norteamérica, Herman Hollerith las utilizaba para el
tratamiento estadístico de grandes volúmenes de infor-
mación; sus máquinas se utilizaron para el censo norte-
americano de 1890 y rápidamente encontraron aplica-
ciones comerciales. Para su fabricación, Hollerith fun-
dó la empresa que algo más tarde se convertiría en la
«International Bussines Machines».
Por otra parte, está la evolución de los autómatas,
meras curiosidades de salón de los siglos XVII al XIX
que imitaban movimientos humanos; hacia 1910 Leo-
nardo Torres Quevedo introducía el concepto moderno
0.12 Notas históricas
de autómata44 , y sugería que, combinados con las téc-
nicas de cálculo electromecánicas, podrían sustituir al
hombre en las cadenas de producción. Como en el ca-
so de Babagge, esta idea tuvo que esperar algunos años
para que la tecnología permitiera su realización. Y tam-
bién como Babbage, Torres se adelantó a su tiempo con
varios conceptos informáticos; por ejemplo, el «tiempo
compartido»: para mejor aprovechar su «aritmómetro»
(construido en 1920) concibió la posibilidad de conec-
tarle varios terminales.
Pero la aportación más importante en este cam-
po de los autómatas es el famoso artículo de Alan
Mathison Turing en el que introducía, teóricamente,
el concepto de autómata abstracto de uso general pa-
ra procesamiento de la información (Turing, 1936). Se-
gún muchos autores, este trabajo resultó ser fundamen-
tal para el desarrollo posterior de los ordenadores (en
él, por ejemplo, ya se sugería la «disyuntiva hardwa-
re/software» mencionada en el Apartado 0.8, y, para
algunos, contenía el germen de la idea de «programa
almacenado», véase más adelante).
Según Eames (1973),
«Fusionando estas tres líneas de desarrollo
[calculadoras, máquinas estadísticas y autóma-
tas], hacia la mitad del siglo XX, llegó a hacerse
posible un tipo totalmente nuevo de máquina: el
computador digital electrónico».
44
De una entrevista publicada en 1915:
«Los antiguos autómatas [...] imitaban el aspecto y
los movimientos de los seres vivos, pero esto no tiene
mucho interés en la práctica, y lo que buscamos es un
tipo de aparato que obvie los meros gestos visibles del
hombre e intente conseguir los resultados que obtiene
una persona para, de ese modo, reemplazar a un hom-
bre por una máquina»
(«Torres and his remarkable automatic devices», Scientific
American, 113, 6, nov. 1915, p. 296).
Según Randell (1982),
«Hay pocas razones para dudar de que, de haber
existido una clara necesidad, Torres habría construi-
do un ingenio analítico completo [...] No fue hasta la
guerra de 1939-1945 que el interés por las máquinas
de cálculo automático llegó a ser bastante fuerte pa-
ra crear el entorno que permitió llevar a la realidad el
concepto de Babbage».
Sobre la obra de Torres Quevedo hay una extensa monografía
de García Santesmases (1980).
39
Los primeros computadores digitales auto-
máticos
En las introducciones históricas de la literatura téc-
nica suele considerarse que el sueño de Babbage (en
Cambridge, Inglaterra) se hizo realidad cuando Howard
Aiken (en Cambridge, Massachussets) construyó el
«Mark I» o ASSC («Automatic Sequence Controlled
Calculator»). Esta máquina electromecánica, con sus
más de 250.000 piezas y más de 800.000 metros de ca-
ble (Aiken y Hopper, 1946) se terminó en 1944 y per-
maneció en uso ininterrumpido durante más de quince
años en la Universidad de Harvard. Sin embargo, algo
antes, entre 1939 y 1943, Konrad Zuse había construi-
do en Berlin una serie de computadores electromecá-
nicos (Zuse, 1962), uno de los cuales, el «Z4», cuatro
o cinco veces más rápido que el ASSC, se utilizó para
cálculos aeronáuticos en las fábricas Henschel (Elgozy,
1979). Su colaborador, Schreyer, propuso la conversión
de esas máquinas a la tecnología electrónica, pero no
encontró financiación para realizarla (Schreyer, 1939,
1941). El problema de Zuse fue carecer de apoyo ofi-
cial (tuvo incluso que interrumpir sus investigaciones
para incorporarse al frente de batalla); su aportación
quedó como un hecho aislado, sin continuidad (y sus
máquinas destruidas por los bombardeos), a diferencia
de lo ocurrido en los EE.UU.
En un proyecto que se mantuvo en secreto duran-
te muchos años (los primeros detalles se publicaron
en 1975) un grupo de científicos británicos (entre los
que estaba Alan Turing) desarrolló una serie de máqui-
nas electrónicas programables, llamadas «Colossus», la
primera de las cuales entró en funcionamiento en 1943
(Randell, 1977). No eran de propósito general, sino es-
pecífico: descifrar los códigos utilizados por los alema-
nes en sus comunicaciones.
Entre los pioneros en proponer la reconversión de las
máquinas calculadoras de tecnología electromecánica a
electrónica hay que citar también a Mauchly (1942). El
primer computador electrónico de propósito general se
debe a Eckert y Mauchly: en 1946, en Pennsylvania,
entraban en funcionamiento, consumiendo 150 Kw, las
18.000 «válvulas» del «Electronic Numerical Integra-
tor and Calculator» (ENIAC), construido por encargo
de la Marina de los EE.UU.
El propio Mauchly, en un artículo retrospectivo, re-
cordaba la construcción del ENIAC y la idea de apli-
carlo a problemas comerciales. «Durante 1945 y 1946,
Eckert y yo pasamos meses en Wall Street tratando de
interesar a la comunidad financiera para que apoyara
40
el desarrollo de una máquina comercial. No creíamos
que fuera difícil venderles algo cuyo futuro era tan ob-
viamente brillante, pero estábamos equivocados... Así,
Eckert y yo, como tantos otros inventores, tuvimos que
autofinanciar nuestro trabajo. Hasta que casualmente
me encontré con unos amigos de la oficina del Cen-
so y me dijeron que querían un computador, y entonces
pudimos arrancar, formando nuestra propia compañía.
El resto es historia» (Mauchly, 1975).
Parte de la historia es que la Eckert-Mauchly Com-
puter Corp. construyó en 1948 un segundo computador,
el BINAC, y desarrolló el UNIVAC 1, primer compu-
tador comercial45 . Un año antes de su lanzamiento, en
1950, la empresa fue absorbida por Remington Rand.
Pero otro hecho histórico, que refuerza el valor de
la frase de Smith citada al comienzo de este Aparta-
do, es que en 1973 una decisión judicial desestimó una
demanda de doscientos millones de dólares interpues-
ta por Sperry Rand contra Honeywell por infracción
de la patente de Eckert y Mauchly. Esta decisión de-
claró inválida tal patente, atribuyendo los derechos de
la invención del computador electrónico digital a John
Vincent Atanasoff, que entre 1939 y 1942 había di-
señado y construido con ayuda de Clifford Berry una
máquina llamada «ABC» (Atanasoff-Berry Computer)
(Mollenhoff, 1974). Más recientemente, algunos auto-
res (Burks y Burks, 1987 y Mollenhoff, 1988) han in-
vestigado sobre los trabajos de Atanasoff y sus influen-
cias en los más conocidos de Aiken, Eckert, Mauchly,
von Neumann, etc.
El programa almacenado
Dice Mauchly (1975) haber tenido la idea de utili-
zar líneas de retardo para almacenar el programa y los
datos, pero que para entonces ya había comenzado la
construcción del ENIAC y prefirió terminarlo en lugar
de recomenzar el diseño. En cualquier caso, el concepto
de programa almacenado se gesta también en la Uni-
versidad de Pennsylvania, y aparece en la propuesta
para el EDVAC (von Neumann, 1945). En 1946 John
von Neumann comienza, en el «Institute for Advanced
Study» (IAS) de la Universidad de Princeton, el desa-
rrollo del ordenador IAS, cuya arquitectura, descrita en
el famoso informe que escribió junto con Arthur Burks
y Herman Goldstine (Burks et al., 1946), se convertiría
45
Un ejemplar de esta máquina, de la que se vendieron cua-
renta y ocho unidades a un precio de 250.000 dólares, se ex-
hibe en el Computer Museum de Boston.
Lección 0. Modelos y niveles
en el modelo de todos los diseños posteriores. Éste es
el informe del que hemos reproducido algunos párra-
fos en esta Lección. En un libro apologético, Goldstine
(1972) presentaba a von Neumann como la figura inte-
lectual más importante del renacimiento austrohúngaro
tras la primera guerra mundial.
No obstante, véase lo que escriben Patterson y
Hennessy a este respecto:
«En 1944, von Neumann empezó a colaborar
en el proyecto ENIAC. El grupo pretendía mejo-
rar la forma de introducir los programas y se dis-
cutió la posibilidad de almacenar los programas
como números; von Neumann ayudó a cristalizar
las ideas y escribió una memoria en la que propo-
nía un computador de programa almacenado lla-
mado EDVAC (Electronic Discrete Variable Au-
tomatic Computer). Herman Goldstine distribuyó
la memoria y puso en ella el nombre de von Neu-
mann, lo que causó gran consternación a Eckert
y Mauchly, cuyos nombres se omitieron. Esta me-
moria ha sido el origen de la expresión común
“computador von Neumann”. Algunos invento-
res pioneros en el campo de los computadores
creen que este término concede demasiado mérito
a von Neumann, que conceptualizó y escribió las
ideas, y demasiado poco a los ingenieros, Eckert
y Mauchly, que construyeron la máquina46 . Como
la mayoría de los historiadores, los autores de es-
te libro (ganadores de la Medalla von Neumann
del IEEE en 2000) creen que los tres desempe-
ñaron un papel clave en el desarrollo del compu-
tador de programa almacenado. El papel de von
Neumann al escribir las ideas, generalizarlas y
reflexionar sobre los aspectos de programación
fue esencial para transferir las ideas a una au-
diencia más amplia».
(Hennessy y Patterson, 2003, pp. 67-68).
Se ha debatido mucho sobre la paternidad de la idea
del programa almacenado. Turing trabajó junto con von
Neumann en el IAS durante dos años, al final de los 30
(Tropp, 1974). Parece que durante la Segunda Guerra
Mundial ambos se entrevistaron en varias ocasiones,
pero se conoce poco de la actividad de Turing en es-
te período, por su vinculación con proyectos secretos
» 46 Curiosamente, en las ediciones anteriores concluía aquí
este párrafo diciendo: “Por este motivo, en este libro no apa-
recerá tal expresión”.
0.13 Orientaciones bibliográficas
británicos (Tropp, 1993). Se dice que von Neumann re-
comendaba siempre a sus colaboradores la lectura del
artículo de Turing (1936), y se ha especulado sobre la
posible influencia de éste en la gestación del concepto
de programa almacenado (Randell, 1972).
En cualquier caso, aquí la historia nos traslada nue-
vamente a Cambridge (Inglaterra), porque, adelantán-
dose al EDVAC, el EDSAC de Maurice Wilkes sería el
primer ordenador de programa almacenado en entrar en
funcionamiento, en 1949 (Wilkes, 1985).
La primera generación de ordenadores
En los dos años que siguen a 1949 numerosos cen-
tros de investigación diseñaron y construyeron prototi-
pos. En 1951 la empresa Engineering Research Asso-
ciates (absorbida también más tarde por Sperry) cons-
truye el «1101», y en 1952 IBM lanza el «701»; son los
primeros de las dos «series» más conocidas de lo que
luego se llamó la «primera generación», caracterizada
por una tecnología electrónica de válvulas de vacío, un
software de sistemas muy primitivo y unos costes de
las máquinas que hoy consideraríamos desorbitados en
relación con su potencia.
0.13. Orientaciones bibliográficas
A lo largo del curso, en estos Apartados, se incluirán
referencias sobre los asuntos tratados en cada Lección.
Empezaremos aquí con algunas de carácter general.
Como indica su subtítulo, el alcance de este libro es-
tá limitado a la arquitectura de ordenadores y los sis-
temas operativos. Para una visión más amplia de la
Informática, un libro excelente es el de Prieto et al.
(2002), que contiene introducciones muy bien elabora-
das a otras materias, como estructuras de datos y algo-
ritmos, periféricos, bases de datos, ingeniería del sof-
tware y redes de ordenadores.
Si el lector está interesado en ampliar detalles y con-
ceptos puede consultar libros sobre arquitectura de or-
denadores, como:
• El libro de Tanenbaum (1999) cubre los mismos te-
mas que éste (de manera más concisa, pero más pro-
funda) e incluye como ejemplos descripciones de los
microprocesadores Pentium, UltraSPARC y picoJava.
• El de Hamacher et al. (2002), que tiene el mismo
nivel, utiliza como ejemplos los procesadores ARM,
68000 y Pentium.
41
• El de Patterson y Hennessy (2003)47 es más avanza-
do. Es, según una opinión bastante extendida que com-
partimos, el mejor libro publicado sobre arquitectura
de ordenadores en el sentido «clásico» (niveles de má-
quina convencional y microarquitectura, y medidas de
prestaciones). Pero para abordar su estudio se requiere
previamente el de un libro más básico (como éste).
• El de Hennessy y Patterson (2004) es una versión
«suavizada» de la primera edición del anterior. Los au-
tores han reelaborado la presentación, añadiendo figu-
ras y cuadros y eliminando material de detalle, pero (y
sólo es una apreciación personal) no lo han converti-
do en el tratamiento de la «interfaz hardware/software»
que promete su título: sigue dando una perspectiva muy
ligada al hardware. Algunos capítulos, como el 6 (en-
cadenamiento) y el 7 (jerarquía de memorias) son mag-
níficos por su claridad.
Y libros sobre sistemas operativos:
• El de Silberschatz et al. (2004) es seguramente
el más utilizado como texto en asignaturas dedicadas
a este tema. Explica los conceptos más importantes
y los ilustra con su implementación en Linux y en
Windows XP. Tiene asociado un sistema simplificado
(pero no tanto como Multialgorítmez), «Nachos», cuyo
simulador es un programa libre que se puede descargar
de la Red.
• El de Tanenbaum (2001) abarca los mismos concep-
tos, e incluye un capítulo sobre sistemas multimedia.
Utiliza como ilustraciones Unix y Windows 2000.
• El de Tanenbaum y Woodhull (1997) es una nueva
edición de un «clásico» (Tanenbaum, 1987) que des-
cribe con todo detalle el código en lenguaje C de una
implementación de Unix llamada «Minix». Como deta-
lle anecdótico, el origen de Linux está en el empeño de
Linus Torvals, cuando era estudiante de segundo curso
en la Universidad de Helsinki en 1991, en mejorar este
sistema (que nunca pretendió ser más que una herra-
mienta didáctica) y hacerlo libre (entonces no lo era: se
vendía con el libro).
En la web se puede acceder a muchos cursos y ma-
teriales. La WWW Computer Architecture Page, en la
dirección http://www.cs.wisc.edu/~arch/www/,
contiene cientos de enlaces. Un documento particular-
mente interesante es el titulado «CPU Design Howto»,
en http://www.tldp.org/HOWTO/48 .
47
Respetando el deseo de los autores, iremos alternando
sus nombres en las referencias a éste y a su segundo libro.
48
Muchas de las referencias que citaremos son direccio-
42
Pasamos ya a citar referencias específicas sobre el
contenido de esta Lección.
El «enfoque sistémico» y las «teorías generales de
sistemas» (o «teorías de sistemas generales») tienen
una larga tradición y una extensa bibliografía. Para pro-
fundizar más en el asunto, Klir (1991) presenta una am-
plia perspectiva de la teoría y una recopilación de trein-
ta y cinco artículos clásicos.
Jerarquías de niveles de abstracción para sistemas
complejos se elaboran, por ejemplo, en Miller (1987)
(para sistemas biológicos y sociales) y en Sáez (1990)
(para sistemas ofimáticos).
Ya en el campo de la descripción de ordenadores,
las jerarquías de niveles más conocidas son la de Bell
y Newell (Siewiorek et al., 1982) y la de Tanenbaum
(1990). La que aquí hemos presentado es una sínte-
sis de ambas, en el sentido de que pretende fusionar la
orientación estructural de la primera con el énfasis fun-
cional de la segunda, y evidencia estos puntos de vista
con el uso de modelos. Una importante aportación con-
ceptual en estas jerarquías (que aquí no hemos explica-
do) es la propuesta de Newell (1982) sobre un nuevo
nivel de abstracción por encima del de máquina simbó-
lica, el nivel de conocimiento, en el que se enmarcan
los trabajos sobre «inteligencia artificial» e «ingeniería
del conocimiento». Dietterich (1986) y Clancey (1989)
han estudiado los procesos de aprendizaje en este nivel,
y Basden (2002) ha hecho una revisión y un profundo
análisis filosófico.
La descripción de la configuración básica «de von
Neumann» se encuentra en todos los libros sobre es-
tructura, arquitectura u organización de ordenadores.
Aquí hemos optado por basarnos en la fuente original
(Burks et al., 1946). En realidad, hay un documento
anterior, la «memoria» a la que se refieren Patterson
y Hennessy en el párrafo reproducido más arriba (von
Neumann, 1945). Pero su lectura es más difícil, y hasta
hace pocos años no se había publicado el texto com-
pleto, cosa que hicieron Godfrey y Hendry (1993), con
un magnífico trabajo de reconstrucción del texto y de
comparación entre la propuesta de von Neumann y la
máquina (EDVAC) que realmente se construyó.
Para detalles históricos, hay una revista cuatrimes-
tral, «Annals of the History of Computing» (publica-
nes de la web. Como es sabido, un problema es que estas
páginas suelen cambiar de dirección, o desaparecer. Una so-
lución parcial es la existencia de un gran archivo que al-
macena contenidos publicados desde 1996. Su dirección es:
http://www.archive.org.
Lección 0. Modelos y niveles
da por el I.E.E.E.), y son muchos los libros editados
con recopilaciones de trabajos de interés histórico; en-
tre ellos, el de Randell (1982), donde pueden encon-
trarse artículos de Torres, Zuse, Aiken, von Neumann,
etc., y el de Pylyshyn y Bannon (1989), que incluye
otros estudios sociales sobre la informática. Para da-
tos «prehistóricos», puede leerse, por ejemplo, Price
(1984), o Corge (1975).
0.14. Ejercicios
Todas las Lecciones terminan con un Apartado que
tiene este título. «Ejercicio» debe entenderse en un sen-
tido amplio. Algunos son problemas bien definidos,
con una o varias soluciones concretas, pero otros son
invitaciones al lector para ejercitar su capacidad crea-
tiva y comprobar que ha asimilado (hecho suyo) el con-
tenido de la Lección (y pueden no tener «soluciones»
en el sentido de un «problema» clásico de libro de tex-
to). De los que siguen, los seis primeros son del primer
tipo (tres se refieren a sistemas continuos y los otros
tres a sistemas discretos), y los restantes, del segundo.
1. Amplíe los modelos de las presas y los preda-
dores (ejemplo 2 del Apartado 0.4) considerando
una nueva variable, RN, que representa la canti-
dad de recursos naturales. RN influye en las tasas
de natalidad y de mortalidad de ambas especies,
y, recíprocamente, las poblaciones influyen tam-
bién sobre RN: su tasa de crecimiento se supondrá
constante, pero su tasa de agotamiento será pro-
porcional al número total de presas y predadores.
2. Para estudiar los cambios en una población de
animales herbívoros se decide empezar por tener
en cuenta dos variables básicas, el número total
de animales (H) y la cantidad de pasto (P ), y las
siguientes relaciones dinámicas:
(a) Los animales, en condiciones favorables
(pasto suficiente), se reproducen con una ta-
sa de natalidad constante (TN /año)) y mue-
ren con una tasa de mortalidad constante
(TM /año; TN > TM ), de modo que, en
esas condiciones:
dH
dt = TN · H − TM · H individuos/año.
(b) El pasto se genera a partir de las sustancias
minerales del suelo, de los residuos orgáni-
cos y de la energía solar (considerados to-
dos fuentes inagotables), de modo que, si
0.14 Ejercicios
los animales no lo consumiesen, crecería
exponencialmente: dP
dt = K · P
(c) Los animales, cuando hay alimento suficien-
te, consumen el pasto con una tasa constan-
te, TC , que se mide en Kg/(individuo·año).
(d) Se considera que hay alimento suficiente si
la cantidad de pasto para cada herbívoro,
PH = P/H, es igual o superior a 10
Kg/individuo. Definimos una variable au-
xiliar, DP , que representa la deficiencia de
pasto por animal, del siguiente modo:
DP = 0 si PH ≥ 10
DP = 1 − PH /10 si PH < 10
(e) En condiciones de alimento insuficiente se
producen los siguientes fenómenos:
• La tasa de mortalidad aumenta en una
cantidad proporcional a DP , con una cons-
tante de proporcionalidad KM .
• La tasa de natalidad disminuye en una
cantidad proporcional a DP , con una cons-
tante de proporcionalidad KN .
• La tasa de consumo de pasto por animal
se divide por (1 + KP × DP ).
Con todos estos datos, elabore un modelo cuali-
tativo en forma de diagrama causal y un mode-
lo procesal en forma de ecuaciones diferenciales.
Analice cualitativamente la dinámica del sistema
(también puede simularlo en un ordenador), y ra-
zone si con este modelo podría explicarse la ex-
tinción de los dinosaurios.
3. Se pretende establecer un modelo básico para el
estudio de la dinámica de una población limitada
por la cantidad total de alimentos, pero tal que la
población, además de consumir alimentos, puede
influir en su elaboración por medio de innovacio-
nes tecnológicas. Se consideran las siguientes va-
riables como principales:
Alimentos, A. Disminuye según una tasa de
consumo de alimentos, TC , proporcional a
la población, y aumenta con una tasa de fa-
bricación de alimentos, TF , función del ni-
vel de tecnología: TF = KF × fF (T )
Población, P . Las tasas de natalidad (TN ) y de
mortalidad (TM ) dependen de la cantidad
de alimentos por persona:
43
TN = KN × fN (A/P );
TM = KM × fM (A/P )
Tecnología, T . Aumenta con una tasa de inno-
vaciones tecnológicas, TT , proporcional al
producto A × P .
Elabore, primero, un modelo estructural (diagra-
ma causal). Después, un modelo procesal (ecua-
ciones diferenciales). Parece razonable que las
funciones fF , fN y fM no sean lineales; dibuje
las formas aproximadas que podrían tener.
4. Un detector de paridad es un sistema digital con
una entrada y una salida, ambas binarias. El valor
de la salida debe ser «0» si el número total de
«1» que se han introducido a la entrada, desde que
comenzó a funcionar, es par (o ninguno), y «1»
si es impar. Obtenga un modelo procesal de este
sistema expresado en las mismas formas que el de
la Figura 0.16.
5. Mi perro tiene un carácter de ordinario apacible.
Normalmente está tranquilo, y en cualquier caso
puede devolvérsele a ese estado ofreciéndole un
hueso. Si huele a un desconocido, ladra y se pone
nervioso. Si se intenta quitarle un hueso gruñe y
se irrita. Si yo le regaño se queda tranquilo, pero
si es un desconocido se pone nervioso e irritado.
Cuando está nervioso e irritado, muerde. He lle-
gado a la conclusión de que se puede prever su
comportamiento con un modelo procesal que tie-
ne en cuenta cinco entradas, cuatro estados y tres
salidas. ¿Qué modelo es ése? (Problema adaptado
de Gilbert, 1976).
6. Explorando un lugar lejano y misterioso, descu-
bre usted un extraño artilugio de origen descono-
cido. Es una caja negra y hermética cuya mono-
tonía sólo se ve interrumpida por la presencia de
tres elementos: una palanca en su parte frontal y
dos protuberancias, una verde (V) y otra roja (R)
en su parte superior. La palanca está bajada (b),
pero parece admitir dos posiciones: arriba (a) y
abajo (b). Por su aspecto, diríase que las protube-
rancias son luces, aunque en este momento están
apagadas. Más curioso que precavido, decide us-
ted experimentar, y comprueba que, en efecto, al
mover la palanca se desencadena una secuencia
de apagados y encendidos de las lámparas, con
un período de un minuto. Toma nota de todas sus
acciones sobre la palanca y de sus efectos, y, codi-
ficando los efectos observados así:
44 Lección 0. Modelos y niveles

00: luces apagadas, ¿Cambian estas nuevas observaciones sus

01: V apagada, R encendida, hipótesis sobre el sistema? ¿Qué nuevas in-
10: R apagada, V encendida, vestigaciones puede hacer, y qué otros mo-
11: las dos encendidas, delos podría proponer?

registra el siguiente comportamiento: 7. La Figura 0.28 es un modelo de este libro. ¿De

qué tipo? Identifique sus aspectos sintácticos, se-
instante palanca luces mánticos y pragmáticos.
0 b 00
1 a 01 8. En el Apartado 0.3 se sugería que el «programa
2 a 10 principal» de la Figura 0.8(c) podría modificarse
3 a 00 automáticamente para que el sistema mejorase su
4 a 01 comportamiento, y, de este modo, «aprendiese».
5 b 10 Trate el lector de extraer sus propias conclusio-
6 a 01 nes, teniendo en cuenta conocimientos básicos de
7 a 10 la psicología: refuerzo (premio y castigo), repre-
8 b 11 sentación del conocimiento, etc., y de extrapolar
9 a 10 (por ejemplo, ¿cuándo podría decirse que el siste-
10 b 11 ma «comprende»?).
11 b 01 9. Trate de reconstruir algunas de las consideracio-
12 b 00 nes que cabe imaginar que se hicieran von Neu-
13 b 00 mann y sus colaboradores. Por ejemplo, habiendo
14 a 01 llegado a la conclusión de fijar en veinte bits la
15 a 10 longitud de las instrucciones, analice las distin-
16 a 00 tas alternativas de diseño en cuanto a número de
17 b 00 instrucciones diferentes y capacidad de memoria
18 a 01 direccionable.
19 a 10
20 b 11 10. Continuando con el tipo de Ejercicio anterior, su-
21 b 01 ponga que se planteasen otro formato de instruc-
22 b 00 ciones, en el que hubiese tres campos: CO, CD1
y CD2, donde CD1 y CD2 indican direcciones de
(a) Establezca un modelo procesal que explique MP en las que se encuentran dos operandos. Las
este comportamiento, y un modelo estruc- instrucciones que operan sobre dos operandos de-
tural que pueda servir de base para la im- jan el resultado en la palabra de memoria inicial-
plementación, con nuestra tecnología, de un mente ocupada por el primero de ellos. ¿Qué ven-
sistema que muestre el mismo comporta- tajas y qué inconvenientes tendría este tipo de or-
miento. ¿Podríamos asegurar que tiene el denador con respecto al anterior?
mismo modelo funcional? 11. Identifique, en cada uno de los niveles de la Fi-
(b) Sigue usted experimentando y observa esto: gura 0.22, los elementos característicos de cada
nivel de abstracción que se han enunciado en el
instante palanca luces Apartado 0.6.
23 b 00
24 a 11 12. Según algunos oráculos (no carentes de funda-
25 a 10 mento) una tecnología basada en moléculas or-
26 a 10 gánicas podría sustituir a la actual de los semi-
27 b 01 conductores. Especule sobre la validez, tras esta
28 b 00 eventual mutación tecnológica, de la jerarquía de
la Figura 0.22.