4.1: Arquitectura de Computadoras y Programación de Computadoras

Procesador Virtual

Es conveniente al programar una computadora tener un modelo mental de la arquitectura subyacente: los componentes o “unidades”, funciones e interconexiones que finalmente implementan el programa. No es importante que el modelo mental corresponda directamente al hardware real de cualquier computadora real. Pero es importante que el modelo mental conduzca a las decisiones correctas en cuanto a cómo escribir programas correctos y eficientes.

Mostramos en la Figura 4.1 la arquitectura para una “computadora virtual”. Hay muchas maneras en las que podemos extender o refinar nuestro modelo para representar con mayor precisión procesos particulares o computadoras particulares de interés: podríamos dividir cada unidad en unidades más pequeñas, por ejemplo, una jerarquía de memoria; podríamos considerar unidades adicionales de propósito especial, por ejemplo para gráficos y visualización; y podríamos replicar nuestra computadora virtual muchas veces para representar (un sistema de) muchos procesos que interactúan. Destacamos que si pones un destornillador a la caja de la computadora, no encontrarías un mapeo uno a uno de nuestras entidades virtuales a los elementos de hardware correspondientes. Pero podrías acercarte.

Ahora describimos los diferentes elementos. En el extremo izquierdo indicamos la memoria. Esta memoria suele ser jerárquica: memoria más rápida y cara en un “caché”; “RAM” más lenta y mucho más extensa. (Tenga en cuenta también que habrá memoria de archivo fuera del procesador a la que se accede a través de funciones de E/S, como se describe en breve) A continuación está la unidad aritmética que realiza las diversas operaciones “básicas” sobre los datos, por ejemplo, asignación, suma, multiplicación y comparación. (El adjetivo “aritmética” para esta unidad es excesivamente restrictivo, pero como en este curso estamos enfocados principalmente en métodos numéricos las operaciones clave son efectivamente aritméticas). También identificamos la “pila de instrucciones” que contiene las instrucciones necesarias para implementar el programa deseado. Y finalmente está la unidad de E/S (Entrada/Salida) que controla la comunicación entre nuestro procesador y dispositivos externos y otros procesos; estos últimos pueden tomar la forma de archivos en medios de archivo (como discos), teclados y otros dispositivos de entrada de usuario, sensores y actuadores (digamos, en un robot), y pantallas.

Observamos que todos los componentes: memoria, unidad aritmética, pila de instrucciones, unidad de E/S están interconectados a través de buses que transportan los datos necesarios entre los diferentes elementos. La unidad aritmética puede recibir instrucciones de la pila de instrucciones y leer y escribir datos de la memoria; de manera similar, la pila de instrucciones puede pedirle a la unidad de E/S que lea datos de un archivo a la unidad de memoria o decir escribir datos de la memoria a una pantalla. Y la unidad aritmética puede comunicarse efectivamente directamente con la pila de instrucciones para controlar el flujo del programa. Estos buses de datos son, por supuesto, un modelo para cables (o rutas de comunicación óptica) en una computadora de hardware real.

Figura 4.1: Procesador virtual

El “I” en la Figura 4.1 significa intérprete. El intérprete toma una línea o líneas de un programa escrito en un lenguaje de programación o “scripting” de alto nivel, como Matlab o Python, de la pila de instrucciones, traduce estas instrucciones en código de máquina y luego pasa estas directivas ahora procesables por máquina a la unidad aritmética para su ejecución. (Algunos lenguajes, como el C, no son interpretados sino compilados: el programa se traduce en masa en código de máquina antes de su ejecución. Como puede imaginar, los códigos compilados normalmente se ejecutarán más rápido que los códigos interpretados).

Por lo general, hay dos formas en las que un intérprete puede alimentar la unidad aritmética. La primera forma, más interactiva con el usuario, es el modo “línea de comandos”: aquí un usuario ingresa cada línea, o pequeño lote de líneas, desde el teclado hasta la unidad de E/S; la unidad de E/S a su vez pasa estas líneas al intérprete para su procesamiento. La segunda forma, mucho más conveniente para cualquier cosa que no sea la más simple de las tareas, es el modo “script”: la unidad de E/S transfiere todo el programa de un archivo preparado por el usuario a la pila de instrucciones; el programa se ejecuta luego a partir de la primera línea a la última. (Esto último es de hecho una simplificación, como veremos cuando discutamos el control de flujo y las funciones). El modo script permite una ejecución mucho más rápida, ya que el usuario está fuera del bucle; el modo script también permite un desarrollo/adaptación mucho más rápido, ya que el usuario puede reutilizar el mismo script muchas veces, solo cambiando datos, o tal vez haciendo correcciones/mejoras o modificaciones incrementales.

Matlab Medio Ambiente

En Matlab la interfaz de usuario es la ventana de comandos. La ventana de comandos proporciona el prompt >> para que el usuario sepa que Matlab está listo para aceptar entradas. El usuario puede ingresar directamente líneas de código Matlab después de la solicitud >> en modo de línea de comandos; alternativamente, en modo script, el usuario puede ingresar >> myscript.m para ejecutar todo el programa myscript.m El sufijo .m indica que el archivo contiene un programa Matlab; los archivos con el sufijo .m son cariñosamente conocido como “m archivos”. (Posteriormente encontraremos archivos de datos de Matlab, que toman el sufijo .mat). Tenga en cuenta que lo más fácilmente ejecutamos programas y subprogramas de Matlab (como funciones, discutidos en breve) desde la carpeta que contiene estos programas; sin embargo también podemos establecer “rutas” que Matlab buscará para encontrar (digamos) myscript.m.

De hecho, Matlab proporciona un entorno completo del cual la ventana de comandos es solo una parte (aunque la más importante). Además de la ventana de comandos, hay una ventana de “carpeta actual” que muestra el contenido del directorio actual, normalmente archivos.m y archivos.mat, pero quizás también otros archivos “no Matlab” (digamos, documento), y proporciona herramientas para la navegación dentro del sistema de archivos de la computadora. El entorno Matlab también incluye un editor —invocado por el menú desplegable “Editar ”— que permite al usuario crear y modificar archivos.m. Matlab también proporciona varias formas de “manual”: doc invoca una amplia ventana de instalación de documentación y capacidad de búsqueda; y, aún más útil, dentro de la ventana de comandos >>help, la palabra clave mostrará una breve descripción de la palabra clave (que normalmente pero no siempre será una función “incorporada” de Matlab). Existen entornos similares, más o menos gráficos, para otros lenguajes de programación (interpretados) como Python.

Observamos que en la práctica real ejecutamos programas dentro de programas dentro de programas. Arrancamos el sistema para iniciar el programa del Sistema Operativo; lanzamos Matlab desde dentro en Sistema Operativo para ingresar al entorno Matlab; y luego dentro del entorno Matlab ejecutamos un script para ejecutar nuestro programa particular (numérico). Es esta última en la que nos hemos centrado en nuestra descripción anterior, aunque las otras capas de la jerarquía son mucho más conocidas por el “usuario general de computadoras”. Por supuesto, es una tarea importante y complicada orquestar estos diferentes programas en diferentes niveles tanto en lo que respecta al control de procesos como también a la gestión de memoria y archivos. Ilustraremos cómo se hace esto a una escala mucho menor cuando discutimos funciones dentro del contexto particular de Matlab.