PCSIM RELOADED

HENRY LEONARDO MORENO DÍAZ

LUCIO GUSTAVO PIRABAN LOZANO

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA

DEPARTAMENTO DE ELECTRÓNICA BOGOTA, D.C.

2004

PCSIM RELOADED

HENRY LEONARDO MORENO DÍAZ

LUCIO GUSTAVO PIRABAN LOZANO

Trabajo de grado para optar al título de Ingeniero Electrónico

Director FRANCISCO VIVEROS MORENO

Ingeniero Electrónico

PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA

DEPARTAMENTO DE ELECTRÓNICA BOGOTA, D.C.

2004

2

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA ELECTRÓNICA RECTOR MAGNÍFICO: R.P. GERARDO REMOLINA S.J. DECANO ACADÉMICO: Ing. ROBERTO ENRIQUE MONTOYA VILLA DECANO DEL MEDIO UNIVERSITARIO: R.P. ANTONIO J. SARMIENTO N. S.J. DIRECTOR DE CARRERA: Ing. JUAN CARLOS GIRALDO DIRECTOR DEL PROYECTO: Ing. FRANCISCO VIVEROS MORENO

3

ARTICULO 23 DE LA RESOLUCIÓN No. 13 DE JUNIO DE 1946 “La universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Solo velará porque no se publique nada contrario al dogma y a la moral católica y porque los trabajos no contengan ataques o polémicas puramente personales. Antes bien, que se vea en ellos el anhelo de buscar la verdad y la justicia.”

4

AGRADECIMIENTOS

Este trabajo de grado fue posible gracias al apoyo incondicional y constante del Ing. Francisco Viveros, quien fue una invaluable guía durante todo el proceso. Igualmente, al Ing. Cesar Bustacara y a la Ing. Alejandra Gonzalez por su apoyo, tiempo y conocimiento aportados, sin los cuales no hubiera sido posible este logro. Agradecemos además a todos aquellos que participaron en nuestro proceso de formación a lo largo de estos años, y a todos aquellos que compartieron con nosotros e hicieron realidad este sueño.

5

A Dios por poner su mano sobre mi hombro y guiar mis pasos siempre por el buen camino.

A mi mamá que me ve desde el cielo por darme sus sabios consejos y que espero

poder seguir durante el resto de mi vida.

A mi papá que siempre me ha dado su apoyo incondicional y al que espero haberle podido cumplir.

A Lucio que me enseñó a ver lo mejor de la vida y ha sido mi fiel compañero hasta

el final.

A Luisa y a Marco, mis primeros amigos en la U. De los cuales aprendí muchas cosas y que a pesar de la distancia, aún cuento con ellos.

Al Ing. Carlos H. Pinzón que me ayudó a tomar la mejor decisión en toda la

carrera.

A la sala de Técnicas Digitales donde aprendí muchas cosas que me servirán durante mi vida como profesional.

A mis cuatro amiguitas Diana C., Diana R., Paula y Lilian que con sus sonrisas y

consejos me alegraron cada día.

A mi familia y al resto de mis amigos que sin su ayuda y compañía no hubiera podido terminar esta carrera.

HENRY L. MORENO D.

6

A Dios por ser mi apoyo y mi guía.

A Henry por acompañarme y ser mi amigo incondicional todo este tiempo.

Al Ing. Mauricio Castillo por todo.

A mi papa por ser un ejemplo.

A mi mama porque siempre tuvo fe en mi.

A mi hermana por ser la persona que admiro.

A Dianita, a Dianis, a Lilian, a Edgar, Jorge Mario, Rosi y Cube por apoyarme y estar ahí cuando más lo necesite.

Al Pacho y al Juancho por ser mis AMIGOS de toda la vida.

A John, Lau, Willy, Paulis, Fercho, Kike, Nelson, Pacho, por compartir tantos

momentos gratos conmigo.

A la sala de Técnicas Digitales, por todo lo aprendido y vivido.

A la Caja Negra por darme la oportunidad.

A Sofia, por ser tan increiblemente especial.

A mis amigos de B&G por ayudarme a crecer.

A todos los que no me creyeron.

LUCIO PIRABAN.

7

CONTENIDO

1. OBJETIVOS................................................................................................................13 1.1. OBJETIVO GENERAL ....................................................................................... 13 1.2. OBJETIVOS ESPECÍFICOS............................................................................... 13

2. METODOLOGÍA .......................................................................................................14

3. ANÁLISIS MANEJO DE MEMORIA .....................................................................16 3.1. CANTIDAD DE OBJETOS EN UNA FORMA .................................................. 16 3.2. CARGA DE FORMAS DESDE EL INICIO........................................................ 26

4. REVISIÓN DEL PROGRAMA.................................................................................29 4.1. PROBLEMA DE JSR........................................................................................... 29 4.2. REVISIÓN DEL CÓDIGO .................................................................................. 29

4.2.1 RETORNO DE SUBRUTINA (RTE) ............................................................ 31 4.2.2 PROBLEMA CON EL AHPL ....................................................................... 32

4.3. INTERRUPCIONES............................................................................................ 32 4.3.1 ALMACENAMIENTO DE REGISTROS DE PROPÓSITO GENERAL....... 32

5. TRABAJOS FUTUROS .............................................................................................34

6. CRITERIOS PARA LA CLASIFICACIÓN DE LOS MÓDULOS.......................35

6.1. MÓDULO UNIDADES COMUNES: ................................................................. 35 6.2. MÓDULO UNIDADES DE MEMORIA:............................................................ 36 6.3. MÓDULO UNIDADES PERIFÉRICOS: ............................................................ 36 6.4. MÓDULO PROCESADOR SIN SEGMENTAR: ............................................... 36 6.5. MÓDULO UNIDADES ALU (UNIDAD ARITMÉTICA LÓGICA): ................ 37 6.6. MÓDULO UNIDADES CACHE: ....................................................................... 37 6.7. MÓDULO UNIDADES PROCESADOR SEGMENTADO Y PREDICTOR DE BIFURCACIONES:......................................................................................................... 37 6.8. MÓDULO UNIDADES DIAGRAMAS DE TIEMPO: ....................................... 38 6.9. MÓDULO UNIDADES DMA:............................................................................ 38 6.10. MÓDULO UNIDAD DE CONTROL MICROPROGRAMADA HORIZONTALMENTE: ................................................................................................. 38 6.11. MÓDULO UNIDAD DE CONTROL MICROPROGRAMADA VERTICALMENTE: ....................................................................................................... 39

7. DEFINICIÓN DE MÓDULOS..................................................................................41 7.1. MÓDULO 1. UNIDADES CENTRALES ........................................................... 41 7.2. MÓDULO 2. PROCESADOR SIN SEGMENTAR............................................. 41 7.3. MÓDULO 3. PROCESADOR SEGMENTADO................................................. 42

8

7.4. MÓDULO 4. UNIDADES AVANZADAS ......................................................... 42 7.5. MÓDULO 5. UNIDADES DE CONTROL MICROPROGRAMADAS UCMP. 42

8. NORMAS DE DOCUMENTACIÓN ........................................................................44 8.1. ESPECIFICACIONES DE LOS MODULOS, UNIDADES Y FORMAS........... 45 8.2. DOCUMENTACIÓN DEL CÓDIGO ................................................................. 46 8.3. CÓDIGO ESTRUCTURADO ............................................................................. 47 8.4. CAMBIOS Y MODIFICACIONES EN EL CÓDIGO......................................... 48 8.5. LISTAS DE REFERENCIAS CRUZADAS........................................................ 49 8.6. DESCRIPCIÓN DE LAS UNIDADES Y FUNCIONES..................................... 50

9. RESULTADOS OBTENIDOS...................................................................................51

10. COSTOS ..................................................................................................................54

11. PROBLEMAS EN EL DESARROLLO DEL TRABAJO DE GRADO............55

12. POSIBLES CAMBIOS EN UNA FUTURA VERSIÓN......................................56

13. CONCLUSIONES...................................................................................................57

14. BIBLIOGRAFÍA.....................................................................................................58

ANEXOS EN CD-ROM......................................................................................................59

9

TABLA DE FIGURAS. FIGURA 1. FORMA PRINCIPAL DE PCSIM V. ........................................................................... 17 FIGURA 2. FORMA PRINCIPAL DE PCSIM RELOADED............................................................ 18 FIGURA 3. FUNCIONES CREAR Y DESTRUIR.............................................................................. 19 FIGURA 4. DECLARACIÓN DE VARIABLES GLOBALES................................................................. 20 FIGURA 5. CREACIÓN DE OBJETOS. ........................................................................................ 21 FIGURA 6. DESTRUCCIÓN DE OBJETOS.................................................................................... 23 FIGURA 7. DEFINICIÓN DE VARIABLES BOOLEANAS.................................................................. 24 FIGURA 8. DIAGRAMA DE FLUJO CREACIÓN DE OBJETOS .......................................................... 25 FIGURA 9. CREACION DE FORMAS. .......................................................................................... 27 FIGURA 10. DIAGRAMA DE FLUJO CREACIÓN DE FORMAS......................................................... 28 FIGURA 11. EJEMPLO DE LA INSTRUCCIÓN JSR ...................................................................... 29 FIGURA 12. EJEMPLO DE LA FUNCIÓN JSR CORREGIDA. ........................................................... 30 FIGURA 13. RUTINA INTERRUPCIÓN ........................................................................................ 33 FIGURA 14. ESPECIFICACIONES DE LAS UNIDADES Y FORMAS.................................................... 45 FIGURA 15. DOCUMENTACIÓN DEL CÓDIGO. ............................................................................ 46 FIGURA 16. CÓDIGO ESTRUCTURADO. .................................................................................... 47 FIGURA 17. CAMBIOS EN EL CÓDIGO. ...................................................................................... 49 FIGURA 18. FORMA PRINCIPAL PCSIM RELOADED ............................................................... 51 FIGURA 19. FORMA PRINCIPAL PCSIM RELOADED CON OBJETOS. ........................................ 52

10

INTRODUCCIÓN En la carrera de Ingeniería Electrónica, bajo la orientación del Ingeniero Francisco Viveros, se han desarrollado una serie de simuladores de un procesador, con la finalidad de facilitar a los estudiantes de Arquitectura I y II el proceso de aprendizaje, permitiéndoles observar de forma sencilla y a la vez detallada el contenido de los registros de propósito general, los registros de la CPU, y ver de forma gráfica la secuencia de las señales de control para manejar la unidad aritmética – lógica, el manejo de los buses, y todas las mejoras en el desempeño que pueden brindársele al procesador haciendo uso de otros módulos como la memoria Caché, el módulo de DMA, etc. Esto permite que el estudiante comprenda con mayor facilidad el funcionamiento de un procesador. PCSIM es un proyecto que posee varios módulos los cuales han sido desarrollados por diferentes grupos de estudiantes, donde cada grupo presenta una forma diferente de solucionar el problema al cual se enfrentaron. Los últimos grupos que trabajaron con PCSIM fueron los que experimentaron los efectos de esta forma de desarrollo, dando a conocer problemas en el programa los cuales se pueden agrupar en dos partes: • Los problemas relacionados con la implementación del software del procesador

y el uso del entorno de programación. • Los problemas relacionados con la transcripción del código AHPL del

procesador. A continuación se explicará cada uno de los problemas con mayor detalle. NORMAS DE DOCUMENTACIÓN Uno de los problemas más graves que se presentaron durante el desarrollo de PCSIM fue la ausencia de una metodología clara para documentar el proceso. Esto hizo que para obtener información acerca de las funciones y los procedimientos ya creados, fuera necesaria la realización de pruebas detalladas, las cuales implican una inversión considerable de tiempo.

11

ADMINISTRACIÓN DE RECURSOS DE MEMORIA Otro problema hace referencia a la estructura de programación empleada por los primeros grupos que trabajaron en este proyecto, dado que no tuvieron en cuenta la eficiencia, ni el manejo dinámico de la memoria. Esto hizo que el programa presentara graves problemas en el manejo de la parte gráfica, haciéndolo poco práctico e inestable. Por estas razones, el programa PCSIM ha llegado a su límite en cuanto a escalabilidad, eliminando cualquier posibilidad de expansión. FUNCIÓN SALTO A SUBRUTINA Durante la ejecución de un programa en el simulador, al ejecutar el OPCODE correspondiente al salto a subrutina, el procesador ejecutaba una operación inválida y no continuaba con la ejecución del programa preestablecido. RUTINA DE INTERRUPCIÓN Si durante la ejecución de un programa se presentaba un llamado a interrupción, el procesador antes de realizar el salto, almacenaba en memoria el contenido del PROGRAM COUNTER, del STATUS REGISTER, del acumulador, y de todos los registros de propósito general. Es común que los procesadores en su mayoría solo almacenen en memoria el PC y el SR, haciendo el llamado a la interrupción mas eficiente y dejando al usuario la opción de almacenar los registros que lo requieran. Los problemas mencionados hicieron que los últimos desarrollos realizados a PCSIM no se pudieran fusionar de la manera deseada originalmente. Es necesario realizar una reestructuración completa del código, como se plantea más adelante, pero todo esto puede tomar bastante tiempo. Entonces, el propósito es definir y orientar dicha reestructuración y señalar unas pautas que permitan que otros grupos continúen con el trabajo y así lograr que PCSIM siga con su desarrollo.

12

1. OBJETIVOS 1.1. OBJETIVO GENERAL Realizar una evaluación minuciosa de todas las posibilidades en cuanto al entorno y las normas de programación, y luego determinar y definir cómo se debe reestructurar el simulador del procesador PCSIM. Así mismo y teniendo en cuenta la magnitud del código del procesador, es necesario realizar una documentación de las partes funcionales del procesador y de dicho código, con diagramas de flujo y de bloques detallados que describan con claridad la arquitectura del procesador y la estructura del código, para que los futuros trabajos en PCSIM entiendan con claridad el funcionamiento del procesador y puedan determinar con facilidad cómo y dónde en la estructura hacer el acople de su trabajo. 1.2. OBJETIVOS ESPECÍFICOS

• Evaluar el entorno de programación actual y definir su viabilidad para reestructurar PCSIM.

• Hacer una revisión completa del código del procesador, para establecer la

forma más sencilla y óptima de redefinirlo.

• Documentar detalladamente la arquitectura del procesador, incluyendo diagramas de bloques.

• Hacer que el código del procesador sea modular, para que en futuros

trabajos la utilización del código existente sea sencilla y rápida.

• Crear una política de documentación y organización del trabajo que facilite el futuro desarrollo del procesador.

13

2. METODOLOGÍA La realización de este proyecto se ejecutó en varías etapas: • Funcionamiento de PCSIM: La primera etapa consistió en entender el

funcionamiento de los módulos de PCSIM, con el fin de comprender cuáles son las entradas y salidas de cada función y cómo se visualizan en pantalla. Junto con esto, se realizó una revisión de la documentación y del código AHPL existente.

• Aprendizaje de DELPHI: Se estudió el entorno de programación DELPHI el

cual se utilizó en las primeras etapas de desarrollo del PCSIM, enfatizando el desarrollo gráfico en sus diferentes formas, precisamente uno de los principales problemas a resolver. Luego de contar con dichos fundamentos, se pudo decidir con un criterio más válido si se podía seguir usando DELPHI para darle continuidad al proceso llevado hasta ahora y no perder el trabajo hecho por los grupos anteriores, o si era necesario detener el proyecto y reescribir el código existente en otro lenguaje que se ajuste más a los requerimientos de PCSIM. Esto pudo haber cambiado totalmente la metodología de aquí en adelante.

• Reestructuración: Luego de haber definido el entorno de programación a

utilizar, el siguiente paso fue iniciar el rediseño del software, comenzando por definir o reformar de la mejor manera su estructura básica y su núcleo funcional, hasta definir los módulos funcionales en los cuales se segmentó el código. Dicha reestructuración debe solucionar todos los problemas mencionados anteriormente.

• Solución de problemas: Ya habiendo definido y analizado cada módulo, se

empezaron a corregir los problemas encontrados en la primera etapa de este proceso, tanto en el diseño teórico del procesador, como en la implementación en software del procesador

• Políticas de documentación: Se precisaron las políticas de documentación

que se adoptaron, y se señaló el camino que los siguientes grupos deben seguir al respecto. Es muy importante porque de esta etapa depende en gran parte que los siguientes grupos puedan acoplarse más rápidamente a lo que ya está hecho.

14

• Pruebas y análisis de resultados: Para terminar, se realizaron pruebas al simulador que determinaron su correcto funcionamiento y desempeño, acorde a los lineamientos planteados.

15

3. ANÁLISIS MANEJO DE MEMORIA PCSIM nació como un proyecto pedagógico que busca facilitar el proceso de aprendizaje de los estudiantes, pero no se esperaba el gran crecimiento que ha tenido con el paso del tiempo. Los primeros grupos que desarrollaron PCSIM no tuvieron en cuenta este crecimiento y no planearon el programa para que fuera claro, estructurado y que tuviera capacidad de crecimiento. Esto llevó a que el último grupo que trabajó en el desarrollo de PCSIM sufriera las consecuencias de estos hechos, llegando al limite de la capacidad en memoria de la forma principal. Este problema se presenta básicamente por dos motivos; la cantidad exagerada de objetos que contenía la forma principal y el hecho de que todos las formas y objetos son cargados en memoria desde el inicio del programa. A continuación se tratarán dichos temas con mayor detalle. 3.1. CANTIDAD DE OBJETOS EN UNA FORMA

DELPHI, al igual que muchos entornos visuales de programación actualmente, permite diagramar formas, colocar objetos y asignarles diferentes propiedades con mucha facilidad. Simplemente se requiere arrastrarlos con el ratón desde una barra de herramientas hasta la posición deseada, asignándole un tamaño y propiedades deseadas. DELPHI se encarga de asignar las propiedades restantes y generar el código necesario.

16

Figura 1. Forma principal de PCSIM V.

En las primeras etapas del desarrollo de PCSIM, se desconocían ciertas limitantes que presenta este entorno, como la cantidad de objetos que puede contener una forma. El problema no fue notable hasta que debido al crecimiento en módulos del simulador, se alcanzara este límite. En la Figura 1, se puede apreciar cómo se colocaban todos los objetos en la forma principal. La gran mayoría de las formas también se cargaban al inicio del programa, y simplemente se mantenían ocultas al usuario. La solución que se presenta es, aprovechando la modularidad del simulador, liberar a la forma principal de objetos, que ésta sólo contenga los objetos que sean necesarios en determinado momento y que culminada su función, dichos objetos sean destruidos para no sobrecargar la forma principal.

17

Figura 2. Forma Principal de PCSIM RELOADED.

En la Figura 2 se puede apreciar que en la nueva versión del simulador, se ha liberado la forma principal de los objetos de la memoria caché, periféricos, y la ventana de Otros Pines, los cuales son creados cuando son requeridos. Algunas de las formas que se cargaban al inicio también han sido modificadas con el mismo fin. Teniendo en cuenta que los objetos se pueden repartir en grupos según los módulos a los que pertenezcan, se presenta la posibilidad de introducir funciones que permitan crear y destruir los objetos cuando cada uno de dichos módulos sea requerido. Dentro de la forma se deben crear dos funciones para cada módulo. La primera que se llame CrearMODULO y la segunda DestruirMODULO, donde “MÓDULO” es la función, unidad o módulo al que se desea convocar.

18

Figura 3. Funciones Crear y Destruir

Dentro de la función CrearMODULO se deben colocar todos los pasos necesarios para la creación y definición de propiedades de los objetos. Este procedimiento debe ser incluido en la sección de los procedimientos públicos, como se observa en la Figura 3. Estos objetos deben ser definidos dentro del código en la sección de definición de variables, ya que de no hacerlo el programa genera un error al compilar. Pero cabe resaltar que el hecho de definir las variables, NO ocupa espacio en memoria, un objeto solo comienza a hacer uso de la memoria cuado es creado.

19

Figura 4. Declaración De Variables Globales.

Para efectos prácticos, se recomienda crear el objeto haciendo uso del entorno gráfico de DELPHI para aprovechar todas sus ventajas, y cuando se tenga el objeto como se desea y en la posición que se desea ubicar, se puede cortar (CTRL+X) de la ventana del entorno gráfico y pegar (CTRL+V) en el archivo de código. Es importante que se utilice la función CORTAR y no COPIAR, ya que de copiarse se generará un error al encontrar 2 objetos dentro del código con el mismo nombre y las mismas propiedades. (Figura 5). Por tratarse de un objeto que es necesario crear mientras se corre el programa y no que se cree al iniciar el simulador, es imperativo agregar dos propiedades que DELPHI por defecto no asigna. Estas propiedades son:

• objeto := TTipo.Create(self); • objeto.Parent := form;

donde “OBJETO” es el nombre del objeto a crear, “TTIPO” es el tipo de objeto que se va a crear (BEVEL, IMAGE, PANEL, etc.); y “FORM” es la forma en la cual estará ubicado el objeto (generalmente la forma principal o “FORM1”)

20

Con la primera línea, se dice de qué tipo será el objeto a crear para asignarle la memoria definida por defecto y las propiedades que le correspondan si es el caso. El parámetro “SELF” permite hacer que el objeto tenga una referencia a sí mismo, para que luego no genere conflictos con el destructor del objeto. En la segunda línea, se le asigna al objeto una forma “PADRE” o “PARENT”, que debe ser la forma en la cual va a aparecer el objeto para establecer una relación jerárquica entre la forma y los objetos creados, permitiendo que el objeto herede algunas propiedades, y para que estos solo se hagan visibles en la forma “PARENT” del objeto creado. Igualmente, al destruir la forma padre, son destruidos los objetos hijos de esta forma, evitando así el llenado de la memoria al dejar objetos creados y sin referencia.

Figura 5. Creación De Objetos.

21

Los objetos deben ser variables globales para que cualquier procedimiento pueda alterar sus propiedades (incluyendo crear y destruir el objeto), inclusive si dicho procedimiento pertenece a otro módulo del programa. Debido a esto, se definió la siguiente nomenclatura para los objetos a crear: FORMobjetoglb donde “FORM” es la forma a la cual debe pertenecer el objeto y “glb” indica que es una variable global. Gracias a esta nomenclatura, se evitan confusiones y conflictos con los nombres de las demás variables del programa. (Figura 4) Al finalizar el uso del objeto o del mismo módulo, es necesario destruir el objeto; para esto se debe introducir una función análoga a “CrearMÓDULO” pero que permita hacer esta operación. En la función “Destrui MODULO” debe ir cada uno de los objetos que se crearon en la función CrearMODULO usando el método “FREE”.

r

objeto.Free; donde “objeto” es el nombre del objeto creado anteriormente. Los anteriores desarrolladores de PCSIM usaban el destructor “DESTROY”. En general los autores recomiendan el uso del método “FREE” en vez de usar el destructor “DESTROY” directamente, ya que éstos presentan algunas diferencias. El destructor “DESTROY” maneja automáticamente el proceso de liberación de memoria. Cuando el programa por alguna razón genera una excepción mientras se está creando un objeto, automáticamente se llama el destructor de dicho objeto para liberar la memoria y las referencias que se hayan creado. Pero este destructor tiene un problema, no revisa antes de liberar el objeto, que las referencias no sean NULL. Este problema se soluciona con el método “FREE”. “FREE” hace uso del destructor “DESTROY”, pero es diferente a éste mismo ya que “FREE” revisa las referencias a NULL de los objetos, evitando así intentar liberar un objeto que no ha sido iniciado.

22

Figura 6. Destrucción de Objetos.

Además, “FREE” hace un llamado automático al procedimiento CLEANUPINSTANCE que libera todos los “STRINGS” asignándoles el valor “EMPTY” y a los tipos de datos “VARIANTS” les asigna el valor “UNASSIGNED” . “FREE” es la forma más segura de liberar memoria. Usando este método, la memoria que se le había asignado al objeto es liberada y mientras no se vuelva a crear, no se puede utilizar porque genera error. (Figura 6) Los anteriores desarrolladores de PCSIM hacían un tratamiento del objeto suponiendo de antemano que el objeto siempre estaba creado, esto les permitía alterarlos desde cualquier parte del programa. Debido a este cambio, se pueden empezar a generar errores, si no se es cuidadoso al hacer los cambios a los objetos que ya hacen parte del programa. Para evitar este tipo de errores, se crea una variable global de tipo BOOLEANA que indique si las funciones CrearMODULO y DestruirMODULO ya fueron ejecutadas respectivamente (Figura 7). Esto con el fin de colocar un condicional en cada lugar del programa donde se haga un llamado a los objetos que pertenecen al módulo y así evitar problemas cuando se quiera llamar a un objeto que aun no ha sido creado. De la misma manera evita crear un mismo objeto varias veces.

23

Figura 7. Definición de Variables Booleanas.

Para evitar conflictos con nombres de otras variables, esta variable se llamará MODULOActiva, donde “MODULO” es el módulo que se desea usar en ese momento (CACHE, PERIFÉRICOS, UCMP, etc.) A esta variable se le asignará el valor “TRUE” cuando se ejecute la función CrearMODULO y respectivamente se le asignará el valor “FALSE” cuando se ejecute la función DestruirMODULO. Cuando se intente crear un objeto durante la ejecución del programa, se debe revisar que dicha variable no tenga el valor “TRUE”, como se muestra en la Figura 5. De ser así, no se debe crear el objeto pues esto indica que los objetos de dicho módulo ya han sido creados. Por defecto, esta variable se debe iniciar con el valor FALSE, haciendo ver que los objetos no han sido creados desde el comienzo del programa.

24

Figura 8. Diagrama de flujo Creación de Objetos

INICIO

MODULOActivo = FALSE

Llamado al módulo

MODULOActivo

Si

Asignación de memoria a los objetos

MODULOActivo =TRUE

Cerrar Módulo

MODULOActivo

FIN

Si

Liberación de memoria de los objetos

MODULOActivo = FALSE

No

CARGA DE OBJETOS

Definición de Propiedades de los objetos

Mostrar OBJETOSObjeto.Visible

No

25

3.2. CARGA DE FORMAS DESDE EL INICIO Cada pantalla que se presenta en un programa es lo que se considera como una forma. La presencia o ausencia de estas pantallas depende de ciertas condiciones que determina el usuario para que aparezcan o desaparezcan. Estas formas pueden ser cargadas todas desde el comienzo del programa y simplemente se hacen visibles o se ocultan cuando así sea requerido. Pero de esta forma se están gastando muchos de los recursos de la máquina porque cada una de estas pantallas tiene asignada permanentemente una parte de la memoria, algo muy similar a lo que pasa con los objetos. Por defecto todas las formas que se creen en el proyecto se cargan desde el comienzo de la ejecución. Para evitar esto, en el menú de DELPHI en Proyecto – Opciones hay una pestaña que dice FORMS (Formas) y en ella aparecen dos tablas: AUTO-CREATE FORMS y AVAILABLE FORMS. Todas las formas que se encuentren en la primera tabla serán llamadas desde el comienzo del programa (todas aparecen por defecto en esta tabla) y aquellas que aparezcan en la segunda tabla solo aparecerán cuando sean creadas en ciertas partes del programa. En PCSIM no todas las formas pueden ser retiradas porque muchas de éstas, poseen procedimientos que son ejecutados desde otras formas, lo que causaría demasiados errores a la hora de la ejecución si no se hace con cuidado. Por este motivo, en la primera parte del desarrollo del trabajo de grado se dedicó una gran cantidad de tiempo en la identificación de estos archivos importantes que se requerían en todo momento y aquellos que solo se necesitan cuando determinado módulo se encuentra activado. Haciendo un cuidadoso análisis a la tabla de referencias cruzadas incluídas en los anexos, se puede tomar la decisión si la forma se debe o no se debe cargar desde el comienzo y si no, escoger el mejor lugar para hacer que se cree y cargue.

26

Figura 9. Creacion de Formas.

El método para asignación de memoria para una forma es la siguiente: if not FORMCreada then begin FORM:=TFORM.Create(self); FORMCreada := TRUE; end; FORM.show; donde FORMCreada es una variable global de tipo booleana que indica si la forma ya fue creada o no. Esto con el fin de saber si se puede en determinados casos ejecutar un procedimiento que pertenezca a esta forma.

27

Figura 10. Diagrama de Flujo Creación de Formas.

INICIO

FORMACreada = FALSE

Llamado a la forma

FORMACreada

Mostrar FORMAForma.Show

Si

Creación y asignación de memoria para la FORMA

FORMACreada =TRUE

No

Cerrar Forma

FORMACreada

FIN

Si

Liberación de memoria de la forma

FORMACreada = FALSE

No

CARGA DE FORMAS DESDE EL INICIO

28

4. REVISIÓN DEL PROGRAMA Uno de los problemas que se ha presentado referente a la trascripción del código AHPL, es el mal funcionamiento de la instrucción Salto a SubRutina (JSR), problema que ningún grupo antes había solucionado. 4.1. PROBLEMA DE JSR Creando un archivo de ejemplo para probar la instrucción JSR y ejecutándola paso a paso, se evidenció que durante la ejecución de dicha instrucción, repentinamente cambiaba a la ejecución de la instrucción SBC (Resta con Carry). En uno de los pasos de esa instrucción, el registro IR almacenaba un valor inconsistente con la ejecución de la instrucción, alterando la secuencia lógica de la misma.

4.2. REVISIÓN DEL CÓDIGO

Ya entrando a hacer una revisión del código justo en ese paso del programa, se encontró la siguiente línea del programa, en la que se veía afectado el valor de IR: unit3.ir := strtoint( concat( inttostr( bites( unit3.ir, 0, 8 )), inttostr( bites( unit_alu.talu_obus, 8, 24 ))));

Figura 11. Ejemplo de la Instrucción JSR

29

La idea de esta línea de código es tomar el valor de MA (24 bits) y reemplazar únicamente los últimos 24 bits del IR (32 bits) y conservar los primeros 8 bits que precisamente son los que tienen la instrucción que se está ejecutando. Después de la ejecución de esta instrucción, el valor cambiaba pero no al valor que se deseaba. Así que eso ameritaba una revisión mas profunda de lo que hacía. La instrucción BITES lo que hace es devolver en una variable de tipo Entero el número decimal equivalente a los bits que se seleccionaron. Esta función se usa en muchas partes del programa y funciona perfecto. El problema viene al usar la función INTTOSTR que deja los mismos números decimales en una variable de tipo String y luego se concatenan generando un número erróneo. El proceso de concatenación es válido cuando la base numérica es hexadecimal.(Figura 11) Para solucionar éste problema, se alteró el código de la siguiente forma

unit3.ir := strtoint( '$' + concat( inttohex( bites( unit3.ir, 0, 8), 2), inttohex( bites( unit_alu.talu_obus, 8, 24), 6)));

Figura 12. Ejemplo de la función JSR corregida.

30

La diferencia con el código anterior, es que en ésta última línea de código se usa la función INTTOHEX que devuelve en forma de String, el equivalente en hexadecimal del entero decimal que retorna la función BITES (Figura 12). Como un parámetro adicional de esta función se debe colocar el número de cifras que desea que retorne la función. Si el número es pequeño, se rellena de ceros a la izquierda. Al momento de concatenar se asegura que estén las ocho cifras del valor del IR (8 cifras hexadecimales equivale a 32 bits). Como la variable IR es de tipo entero y hasta ahora lo que se tiene es un String con el número equivalente en hexadecimal, se le concatena al comienzo un signo de $ que significa que el número está en base hexadecimal y la función STRTOINT puede hacer la conversión de forma correcta. Después de varias pruebas con esta nueva línea de código, el programa ya pasaba de forma correcta ese paso del AHPL que antes no lo hacía.

4.2.1 RETORNO DE SUBRUTINA (RTE) Como una consecuencia lógica del mal funcionamiento de la función de salto a subrutina, la función de Retorno de Subrutina tampoco había sido probada nunca. A la hora de probar esta función se presentó el problema de que no se recuperaban correctamente los valores de la memoria señalados por el SP, cargando en el registro PC contenido erróneo, afectando así la ejecución. Al observar con detenimiento el SP cada vez que iniciaba el programa, se observó que éste tomaba un valor de forma aleatoria entre 0 y FFFFFF. La memoria ROM del procesador PCSIM va desde la posición 000 hasta la posición 3FF y la memoria RAM está comprendida entre las posiciones 400 y BFF. Como se puede apreciar, el valor que puede tomar el SP puede quedar muchas veces por fuera del rango de memoria válida. Así que se obligó a que el SP tuviera como valor inicial C00 ya que como primer paso antes de guardar el valor del PC durante el salto a una subrutina, el SP se decrementa en uno, apuntando a una posición válida de memoria RAM. Con este nuevo valor en el SP y después de muchas pruebas, se observó que las funciones de salto y retorno de Subrutina funcionan de manera correcta.

31

4.2.2 PROBLEMA CON EL AHPL En las pruebas que se hicieron del JSR, hubo un caso en el que cual se observó que dos de las instrucciones no eran correctas. Es el caso del modo directo del JSR. Una breve explicación del proceso:

IR[0:31] MD[0:31]; MA[8:31] MD[8:31 ; IR[8:31] MA[8:31];

]

]

dejando al final en IR el mismo valor que estaba desde la ejecución de la primera instrucción. Haciendo una revisión del AHPL, se tiene contemplado de esta forma desde ahí. Lo que ocurre es que en el segundo paso hay una condición, y ésta es que si es un salto con direccionamiento indizado directo, el paso sea:

MA[8:31] MD[8:31 + IX[0:23]

permitiendo que en el tercer paso se guarde una copia de esta nueva dirección en el IR. Si es solo modo directo, el IR no sufre ningún cambio. Para este problema no fue necesario darle una solución ya que funciona de acuerdo a lo planteado en el código AHPL.

4.3. INTERRUPCIONES

Cuando un periférico genera una interrupción para el procesador, éste procede a ejecutar una serie de pasos que no hacen parte de la función principal que se estaba cumpliendo. Algunos de estos pasos son propios del procesador y otros son dados por el programador.

4.3.1 ALMACENAMIENTO DE REGISTROS DE PROPÓSITO GENERAL En el momento que se presenta una interrupción, solo es necesario almacenar por defecto los registros “PROGRAM COUNTER” (PC) y el “STATUS REGISTER” (SR) que son importantes para el correcto funcionamiento del programa que se estaba ejecutando antes de presentarse la interrupción. Los demás registros solo serán almacenados si el programador así lo requiere. Según el código AHPL de PCSIM, se estaban almacenando todos los Registros de Propósito General (RPG) que

32

estaban creados y así se encuentra actualmente en el AHPL del procesador. Esto hace ineficiente el salto a la rutina de interrupción. Siguiendo la tendencia de los procesadores en la actualidad, se debe dejar al programador la libertad de escoger qué información desea almacenar al hacer el salto a la rutina de interrupción. Por esta razón, se alteró el código para que por defecto se almacenara únicamente el SR y el PC, dándole al programador la libertad de guardar los demás registros. Lo que se hizo fue alterar el código para evitar la ejecución de estos pasos en la rutina de interrupción, pero sin eliminarlos. Esto, previniendo que en un futuro estos pasos vuelvan a ser necesarios con fines didácticos; en dicho caso su restauración será sencilla y así se podrá asegurar el correcto funcionamiento del simulador.

Figura 13. Rutina Interrupción

33

5. TRABAJOS FUTUROS

Durante el desarrollo del presente Trabajo de Grado, se han modificado muchas líneas de código, con el fin de solucionar los problemas anteriormente mencionados. Pero debido a la inmensurable magnitud del problema y la extensión del código que abarca varios trabajos de grado, era un trabajo demasiado largo para un solo grupo modificar el código de todo el procesador, tal y como se dijo en los objetivos y en el cronograma presentado inicialmente. Por esta razón se planteó inicialmente buscar, mediante un estudio detallado, las soluciones apropiadas para los problemas que se enfrentaban, y luego marcar las pautas para que en un futuro otras personas pudieran continuar con el proceso de restauración del procesador. Se revisaron y solucionaron los problemas encontrados en cuanto a inconsistencias entre el código del procesador y el AHPL planteado, también los problemas debido a fallas en el código, y problemas referentes a manejo de memoria y carga de formas y objetos, en el módulo de UNIDADES COMUNES. Adicionalmente, se solucionaron los problemas de la carga de formas y objetos en las unidades de PERIFÉRICOS, CACHE y para la ventana de OTROS PINES, del menú VER. A continuación se plantea una posible división de los trabajos futuros de PCSIM, que permita culminar esta labor en el menor tiempo posible.

34

6. CRITERIOS PARA LA CLASIFICACIÓN DE LOS MÓDULOS Es importante tener en cuenta muchos factores a la hora de definir los módulos en los que se piensa dividir PCSIM para realizar una revisión: Total de archivos de código: Existen 92 archivos de código los cuales tienen

una determinada función. Hay algunos que cumplen más de una función.

Extensión de los archivos: En las primeras versiones de PCSIM todas los cambios y modificaciones se realizaban sobre el archivo base. Pero en las últimas versiones se han hecho las modificaciones creando varios archivos, cada uno cumple una función específica. Esto hace el código más comprensible, pero el número de archivos aumentó en número.

Función del código: Si van a ser varios los grupos que trabajen en la renovación del código de PCSIM, lo mejor es que cada grupo se especialice en una función del programa y no altere archivos al azar de los que no conozcan claramente su utilidad. Otro detalle importante es que para poder comprender el código de algunos archivos se hace necesario conocer el de otros porque llaman funciones que fueron implementadas en otras partes.

Documentación: Ya que han sido varios los grupos de personas que han

trabajado en PCSIM, cada uno de estos grupos realizó la documentación de su correspondiente parte a su manera. Si se quiere realizar una consulta del código, no es práctico revisar los libros de cada una de los trabajos de grado, es práctico encontrar la documentación básica en el mismo código.

Estructura de PCSIM: Es bueno tener en cuenta la arquitectura que tiene el

procesador y dividir en una forma similar los módulos de PCSIM. Esto hace mas fácil hacer comprender la arquitectura del procesador y todas sus funciones. Además, la división que poseen actualmente algunos de los archivos de código de PCSIM están ligeramente relacionados con este punto.

6.1. MÓDULO UNIDADES COMUNES: En éste módulo se encuentra el núcleo del programa, es decir, es la unidad base que se encarga de llamar a todas las funciones secundarias (alu, registros, diagramas de tiempo, etc), así mismo de darles prioridad y administrar los

35

recursos. Así mismo, se encuentran aquellas funciones que no estan relacionandas con la arquitectura del procesador. Tenemos: UNIT1,FORM1: Unidad Principal. UNIT3, FORM3: Manejo de registros. UNIT7, FORM7: Ventana de error. UNIT13: Unidad de desensamblador. UNIT14, FORM14: Unidad de Presentación. UNIT15, FORM15: Registros de Propósito General. UNIT16, FORM16: Ventana de número de registros. UNIT19: Unidad para deshacer el último paso. UNIT_CREDITOS, CREDITOS: Ingenieros de Desarrollo PCSIM2000. 6.2. MÓDULO UNIDADES DE MEMORIA: Como su nombre lo indica, son las funciones relacionada al manejo de las memorias ROM y RWM. UNIT4, FORM4: Ventana de memoria RWM. UNIT5, FORM5: Unidad para el manejo del mapeo de memoria. UNIT6: Unidad de simulación de memoria. UNIT8, FORM8: Ventana para seleccionar posición de memoria. UNIT12, FORM12: Ventana de memoria ROM. UNIT20, FORM20: Ventana que pregunta "Qué memoria desea guardar?". 6.3. MÓDULO UNIDADES PERIFÉRICOS: Estan son las unidades que se encargan de manejar los periféricos, su simulación y presentación de resultados en pantalla. UNIT17, FORM17: Unidad de periféricos. UNIT18, FORM18: Ventana para escoger el número de cada periférico y la prioridad. 6.4. MÓDULO PROCESADOR SIN SEGMENTAR: UNIT9: Unidad de ejecución de instrucciones 1. UNIT10: Unidad de ejecución de instrucciones 2. UNIT11: Unidad de ejecución de instrucciones 3.

36

6.5. MÓDULO UNIDADES ALU (UNIDAD ARITMÉTICA LÓGICA): Como su nombre lo indica, son las funciones relacionadas con la ALU del procesador: UNIT_ALU, FORM_ALU: Unidad que realiza todas las operaciones y funciones de la ALU. UNIT_ALUPINT: Unidad que pinta el comportamiento interno de la ALU. UNIT_CLA, FORM_CLA: Unidad de sumador de 32 bits con cuatro carry-look-ahead. 6.6. MÓDULO UNIDADES CACHE: Estas son todas las unidades encargadas de manejar el uso y simulación de la memoria cache: UNIT_CACHE1, FORM_CACHE1: Unidad que crea la ventana de MMU (MEMORY MANAGEMENT UNIT) de registros. UNIT_CACHE2, FORM_CACHE2: Unidad que crea la ventana de Caché. UNIT_CACHE3, FORM_CACHE3: Unidad que crea la ventana para habilitar/deshabilitar Caché. UNIT_CACHE4, FORM_CACHE4, Unidad que crea la ventana de topología interna de MMU (MEMORY MANAGEMENT UNIT). UNIT_CACHE5: Unidad de pasos de AHPL de la Caché. UNIT_CACHE6: Unidad para pintar buses y actualizar registros. UNIT_CACHE7: Unidad para pintar buses y actualizar registros. UNIT_CACHE8: FORM_CACHE8, Unidad que crea la ventana de la tabla TR. UNIT_CACHE9, Unidad para deshacer el último paso de Caché. 6.7. MÓDULO UNIDADES PROCESADOR SEGMENTADO Y PREDICTOR DE

BIFURCACIONES: UNIT_PIPE1: Unidad para pintar Procesador Segmento. UNIT_PIPE2: Unidades del Procesador Segmentado. UNIT_PIPECONTROL: Unidad de Control para el Procesador Segmentado. UNITRIESGOS: Unidad evaluadora de Riesgos. UNITPREDICTOR: Unidad de Predicción de Bifurcaciones. UNIT_PIPEDIAG_ET, FORM_PIPEDIAG_ET: Unidad manejadora de ventanas del Pipeline.

37

6.8. MÓDULO UNIDADES DIAGRAMAS DE TIEMPO: Aunque no es parte de la arquitectura del procesador, se tiene un módulo para las unidades que manejan la simulación con diagramas de tiempo, ya que es una parte el código relativamente grande: UNIT_DIAGRAMAT, FORM_DIAGRAMAT: Comportamiento gráfico de las señales. UNIT_DIAGRAMACONF, FORM_DIAGRAMACONF: Configuración gráfica de señales. UNIT_SAVECHECK, FORM_SAVECHECK: Guardián de guardar página gráfica. 6.9. MÓDULO UNIDADES DMA: Aquí se encuentran todas las funciones relacionadas con el DMA (DIRECT MEMORY ADDRESSING) y el arbitraje de los buses: UNIT_DMA1, FORM_DMA1: Unidad de presentación interna del DMA1. UNIT_DMAPASOS: Unidad de ejecución del DMA1. UNIT_DMAREG: Unidad del registro de estado rcomm del DMA1. UNIT_DMAPINTAR: Unidad de cambios en pantalla tanto externo como interno al DMA1. UNIT_DMA2, FORM_DMA2: Unidad de presentación interna del DMA2. UNIT_DMAPASOS2: Unidad de ejecución del DMA2. UNIT_DMAREG2: Unidad del registro de estado rcomm del DMA2. UNIT_DMAPINTAR2: Unidad de cambios en pantalla tanto externo como interno al DMA2. UNIT_DMA3, FORM_DMA3: Unidad de presentación interna del DMA3. UNIT_DMAPASOS3: Unidad de ejecución del DMA3. UNIT_DMAREG3: Unidad del registro de estado rcomm del DMA3. UNIT_DMAPINTAR3: Unidad de cambios en pantalla tanto externo como interno al DMA3. UNIT_ARBITRO: Unidad para manejo del arbitro (Lógico y gráfico). 6.10. MÓDULO UNIDAD DE CONTROL MICROPROGRAMADA

HORIZONTALMENTE: MEMORIA_UCMP: Unidad para la visualización del archivo de memoria. UNIT_UCMPHORIZONTAL: Unidad para la visualización de la arquitectura de la UCMP, lectura y ejecución. UNIT_UCMPALABRA: Unidad que genera las flechas de la palabra de control.

38

UNIT_SRCONTROL: Unidad para la visualización de señales de control SRCONTROL. UNIT_RCONTROL: Unidad para la visualización de señales de control RCONTROL. UNIT_CARGAR: Unidad para la visualización de señales de control CARGAR. UNIT_CALU: Unidad para la visualización de señales de control CALU. UNIT_CBUSINT: Unidad para la visualización de señales de control CBUSINT. UNIT_CBUSEXT: Unidad para la visualización de señales de control CBUSEXT. UNIT_OTROS: Unidad para la visualización de señales de control OTROS. UNIT_LOGICASECUENCIAMIENTO: Unidad para la visualización de la lógica de secuenciamiento. UNIT_EJECUCIÓN: Unidad de ejecución de la unidad de control microprogramada. 6.11. MÓDULO UNIDAD DE CONTROL MICROPROGRAMADA

VERTICALMENTE: UCMV_UNIT, UCMVFORM: Unidad de la arquitectura de la Unidad de Control Microprogramada Verticalmente. VERTICALMEMORY_UNIT, VERTICALMEMFORM: Unidad de la memoria de control de la UCMV. SRCONTROLU1, SRCONTROLF1: Unidad de visualización de SRControl en la forma principal, contiene los bits de salida de la UCMV. RCONTROLU1, RCONTROLF1: Unidad de visualización de RControl en la forma principal, contiene los bits de salida de la UCMV. CARGARU1, CARGARF1: Unidad de visualización de Cargar en la forma principal, contiene los bits de salida de la UCMV. CALUU1, CALUF1: Unidad de visualización de CALU en la forma principal, contiene los bits de salida de la UCMV. CBUSINTU1, CBUSINTF1: Unidad de visualización de CBUSINT en la forma principal, contiene los bits de salida de la UCMV. CBUSEXTU1, CBUSEXTF1: Unidad de visualización de CBUSEXT en la forma principal, contiene los bits de salida de la UCMV. INOUTUNIT, INOUTFORM: Unidad de visualización de Entradas/Salidas de la Unidad Lógica de Secuenciamiento. GEN_DIR_UCMV, GENFORMUCMV: Unidad de visualización de la generación de direcciones de la Unidad Lógica de Secuenciamiento. BIFURUNIT_UCMV, BIFFORM: Unidad de visualización de la decodificación de la dirección de bifurcación. VERTICALWORD_UNIT, VERTICALWORDFORM: Unidad de visualización del esquema de la palabra de control. CSRCONTROLUNIT, CSRCONTROLFORM: Unidad de visualización de la ayuda de codificación de SRControl.

39

CRCONTROLUNIT, CRCONTROLFORM: Unidad de visualización de la ayuda de codificación de RControl. CCARGARUNIT, CCARGARFORM: Unidad de visualización de la ayuda de codificación de Cargar. CCALUUNIT, CCALUFORM: Unidad de visualización de la ayuda de codificación de CALU. CCBUSINTUNIT, CCBUSINTFORM: Unidad de visualización de la ayuda de codificación de CBUSINT. CCBUSEXTUNIT, CCBUSEXTFORM: Unidad de visualización de la ayuda de codificación de CBUSEXT. COTRASUNIT, COTRASFORM: Unidad de visualización de la ayuda de codificación de Otras. CBIFURUNIT, CBIFURFORM: Unidad de visualización de la ayuda de codificación de Bifurcación.

40

7. DEFINICIÓN DE MÓDULOS Tomando en consideración los criterios anteriormente mencionados, se propone la división del código en los siguientes módulos: 7.1. MÓDULO 1. UNIDADES CENTRALES En este módulo se encuentra el núcleo del programa que tiene una gran parte del código y es la columna vertebral de PCSIM. Adicionalmente se encuentran las unidades correspondientes a las memorias ROM y RWM, porque se consideran unidades básicas y están muy relacionadas con el núcleo del procesador. Las unidades que manejan los periféricos son un módulo sencillo, y a pesar de que está en parte relacionado con las unidades de DMA, hace uso principalmente de las funciones encontradas en las Unidades Comunes, por esta razón se incluyen en este módulo. • UNIDADES COMUNES. • UNIDADES DE MEMORIA. • UNIDADES PERIFÉRICOS. 7.2. MÓDULO 2. PROCESADOR SIN SEGMENTAR El procesador sin segmentar es un esquema básico del procesador, que muestra una arquitectura tal como se plantea en la asignatura de Arquitectura de Procesadores I. Hace uso de las memorias, de los registros de propósito general (RPG) como son el acumulador (AC), el registro de instrucciones (IR), el registro de dirección de memoria (MA) y el registro de datos de memoria (MD). También hace uso de la Unidad Aritmética Lógica ALU, pero además de éstos, no utiliza las demás unidades de PCSIM.

41

Es una parte extensa de código y es fundamental que funcionen correctamente porque sobre éstas están apoyadas muchas de las demás funciones de PCSIM. Por esta razón se incluyen en este modulo las siguientes unidades: • PROCESADOR SIN SEGMENTAR. • UNIDADES ALU. 7.3. MÓDULO 3. PROCESADOR SEGMENTADO El procesador segmentado es una arquitectura un poco más compleja que la del procesador sin segmentar, ya que ésta hace uso de las funciones de PIPELINE para poder realizar funciones en paralelo y así incrementar el desempeño del procesador. Esto implica que la complejidad del procesador aumenta. A causa de esto, se implantaron las unidades de los diagramas de tiempo, que aunque también se pueden utilizar para el procesador sin segmentar, presentan mayor utilidad para la comprensión de las funciones de PIPELINE. Por esto se incluyeron las siguientes unidades:

• PROCESADOR SEGMENTADO. • DIAGRAMAS DE TIEMPO.

7.4. MÓDULO 4. UNIDADES AVANZADAS Estas unidades hacen parte de las funciones avanzadas de PCSIM, pero las unidades de memoria y periféricos, con las cuales están profundamente relacionadas, hacen uso de las unidades comunes. En cambio estas unidades tienen sus propias formas y hacen uso de sus propias funciones, tanto como para la simulación, como para el entorno gráfico. Por esta razón se agruparon es un solo módulo.

• UNIDADES CACHE. • UNIDADES DMA.

7.5. MÓDULO 5. UNIDADES DE CONTROL MICROPROGRAMADAS UCMP.

42

Estas unidades fueron trabajadas por los dos últimos grupos que desarrollaron PCSIM, y como se ha mencionado anteriormente, presentaron una propuesta de solución a los problemas que encontraron. De ser necesario en un futuro, estas dos unidades deberán ser modificadas siguiendo los lineamientos planteados. Además estas unidades están íntimamente relacionadas. Por estas razones se unieron en un solo módulo.

• UNIDAD DE CONTROL MICROPROGRAMADA HORIZONTALMENTE. • UNIDAD DE CONTROL MICROPROGRAMADA VERTICALMENTE.

La definición por módulos descrita anteriormente, está sujeta a modificaciones durante el desarrollo del trabajo de grado y dependiendo de las soluciones planteadas y de la complejidad de los problemas que presente cada módulo.

43

8. NORMAS DE DOCUMENTACIÓN Como se mencionó en el anteproyecto, el software generalmente está en constante evolución, y PCSIM no es la excepción a dicha regla. Es un programa que tiene como filosofía ayudar en el proceso de formación de los estudiantes de arquitectura de procesadores, y así como los procesadores evolucionan en su tecnología permitiéndoles mayor rapidez y eficiencia, PCSIM debe ser una herramienta flexible, que sea fácilmente accesible para un programador y le permita así implementar unidades y tecnologías nuevas para continuar con su desarrollo. Una de las bases más importantes, sino la más importante para ayudar a un programador a la comprensión del código, es la documentación detallada y precisa del código. Inclusive para un programador experto, es muy difícil comprender un programa sin la documentación adecuada, sin olvidar la gran inversión de tiempo que debe realizar en dicha labor. Por esta razón, se han definido ciertas normas de documentación que le brinden claridad al código fuente de PCSIM; y es de vital importancia que esta documentación se realice siguiendo los lineamientos establecidos para no dificultar la evolución de PCSIM. Es necesario que estas normas se apliquen durante el proceso de desarrollo del software, ya que entre los ingenieros electrónicos no es común la cultura de documentar los procesos, y esto se debe a que generalmente los proyectos son manejados por una persona o un grupo hasta el final, y algunas veces no se promueve o contempla la posibilidad de que otra persona o grupo continúe con dicho proyecto. Otro error común es dejar la fase de documentación para cuando se finalice el proyecto, ya que en esta etapa de los proyectos generalmente parece inútil o una perdida de tiempo realizar dicha documentación, y muchas de las cosas que al comienzo del proyecto o durante su desarrollo fueron importantes, en esta etapa ya no se recuerdan y esto se traduce en una documentación pobre, si no inexistente, del código. La documentación pobre se traduce inevitablemente en una inversión de tiempo mucho mayor luego, y dicha falta de documentación inevitablemente esconde errores del programa, o en muchos casos, hace parecer que existen líneas de código o instrucciones inútiles, sin ningún propósito, pero en realidad, lo que ocurre es que su función no este especificada en ningún lugar y por eso parecen

44

sobrantes. Puede ocurrir que en realidad sean instrucciones inútiles, o que se podrían implementar de una forma mas eficiente, clara, etc., pero un programador sin la documentación adecuada no se atrevería a modificarlas por temor a afectar alguna otra parte del programa. Lo siguientes son algunos de los lineamientos que se proponen para la documentación de PCSIM 8.1. ESPECIFICACIONES DE LOS MODULOS, UNIDADES Y FORMAS. PCSIM se ha segmentado en ciertos módulos dependiendo de las funciones que cumplen las unidades que los conforman. Dichas unidades a su vez contienen formas y variables que cumplen funciones específicas. Cada vez que se cree un módulo nuevo o una unidad nueva, debe especificarse la o las funciones que se realizan, como se muestra en la Figura 14. En el caso de los módulos, debe llevarse un documento que mencione la función específica de cada módulo nuevo, los datos que requiere y con cuales otros módulos se relaciona. De ser clara la función del módulo.

Figura 14. Especificaciones de las unidades y formas.

45

En el caso de las unidades, esta documentación debe ser mucho más explícita. Debe estar escrita cual es la función específica de cada unidad, incluir todos los datos que necesita de entrada, las variables que requiere de otras unidades, cualquier consideración teórica, matemática, de tiempos de ejecución, o consideraciones de razonamiento esenciales para el funcionamiento de la unidad. Igualmente debe estar escrito en que casos se utiliza dicha unidad, que función la utiliza y porque. 8.2. DOCUMENTACIÓN DEL CÓDIGO Es tal vez la forma más importante de documentación, ya que representa gran parte de la claridad que puede tener el código. Es importante que a medida que se va desarrollando el código, en paralelo se vaya realizando la documentación de las funciones. Estas notas deben explicar detalladamente y con claridad, en un lenguaje apropiado al contexto, que cosas están pasando y el porque de dicha operación.

Figura 15. Documentación del código.

46

Dichos comentarios del código no deben simplemente resaltar la operación que se está realizando, ya que no dicen nada nuevo al programador. Deben hacerse pensando en que la persona que los va a leer no conoce aún el código, y deben dar información clara y concisa (Figura 15). El código adecuadamente documentado puede ser leído por cualquiera que conozca el entorno de programación para obtener una comprensión detallada del programa. 8.3. CÓDIGO ESTRUCTURADO Es otra de las partes vitales para la comprensión de un código desconocido. Se refiere a todo aquello que ayude a que el código sea más claro y comprensible, sin ser los comentarios que se usan para documentar el código. Es un tema muy amplio y aun no está todo dicho acerca del tema, pero en general, se dice que es todo aquello que ayuda a darle estructura al código. En general, los nombres de las variables que se utilizan deberían contener la información referente a su función y/o a la información que contiene. Nombres de variables como “aux1” reducen notablemente la estructura del código. Los nombres de las variables deben ser expresivos sin importar su longitud, mientras el entorno lo permita, tal como se observa en la Figura 16.

Figura 16. Código Estructurado.

47

En general entre los programadores, frecuentemente se hace uso de algunos trucos que pueden brindarle al programa eficiencia, velocidad, menos espacio en memoria, etc., pero estos trucos generalmente solo son entendidos por el programador y aunque funcionen correctamente, le restan estructura al código, al hacerlos misteriosos y desconocidos para otros que vean el código. En lo posible es recomendable evitar dicha clase de maniobras de programación para no restarle estructura al código. Una disposición pobre del programa en sí, reduce la estructura del programa. Un programa bien estructurado tiene un flujo lógico del programa y de sus rutinas de ejecución. Las funciones que ocurren al principio del programa aparecen primero, y las funciones consiguientes deben estar ubicadas en lo posible siguiendo un diagrama de flujo de la ejecución. Aquellas funciones que se utilizan varias veces durante la ejecución del programa, deben estar agrupadas y marcadas como tal. Cada una de estas funciones debe tener en lo posible, un solo punto de entrada y de salida, de lo contrario debe estar claramente especificado. La principal regla que se debe seguir con en fin de darle estructura al código, es hacer todas las elecciones posibles para hacer que el código sea mas comprensible para otras personas. 8.4. CAMBIOS Y MODIFICACIONES EN EL CÓDIGO Es una tarea extremadamente sencilla, pero igualmente importante a todas las otras normas mencionadas. Generalmente, con el transcurso del tiempo será necesario realizar cambios en el código, que igualmente puede ser algo tan sencillo como agregar más código al ya existente. Es necesario que cada cambio que se realice en el código ya existente se documente en el mismo código, indicando la persona o el grupo que realizó el cambio, la fecha del cambio, las razones para realizar dicho cambio, y de ser necesario para dar claridad, dejar el código antiguo como un comentario, señalando que es la parte del código que se acaba de modificar.(Figura 17)

48

Figura 17. Cambios en el código.

Esto agrega estructura al código y permite que el código tenga una forma de contar su historia a través del tiempo. También se evita así el grave problema de realizar cambios sobre los cambios, una falla que es muy difícil de detectar, pues no existe correspondencia entre las razones para realizar los cambios y la función que cumplen dichos cambios. 8.5. LISTAS DE REFERENCIAS CRUZADAS Son muy importantes cuando se trabaja en un programa que se ha planeado y estructurado para ser altamente modular y con una gran capacidad de expansión como PCSIM. Estas listas de referencias detallan con claridad las relaciones entre módulos o unidades, hablando de variables o funciones. Estas listas permiten saber como se relacionan los módulos o unidades del código y en caso de necesitarse una modificación, se puede saber con exactitud que funciones son afectadas al realizar un cambio. Igualmente, ayuda a saber si existen funciones que puedan ser reutilizadas, aunque esto no es recomendable ya que le resta modularidad la código.

49

8.6. DESCRIPCIÓN DE LAS UNIDADES Y FUNCIONES Al inicio de las unidades y funciones debe ser documentado, de forma precisa, la utilidad de las mismas. También es importante intentar que el nombre de la función o unidad describa en buena parte su labor. Esta tarea es mucho más importante cuando se trata de funciones que se utilizan muchas veces a lo largo del código. Es evidente que existen muchas funciones que para ser descritas no necesitan un texto extenso, pero no por ello deben ser obviadas. Debe tener suficiente detalle para que en el futuro cualquier error o cambio que fuera necesario, se pueda realizar con facilidad. Estos comentarios no deben estar escritos en un lenguaje técnico, al contrario, es preferible un lenguaje sencillo y familiar, ya que la idea no es impresionar al programador, sino orientarlo y ayudarlo. Si es apropiado o pertinente, se pueden incluir referencias a variables o a líneas de código para hacer mas claro el funcionamiento de la función.

50

9. RESULTADOS OBTENIDOS En los objetivos planteados, se perseguía la meta de que el código de PCSIM fuera más claro y sencillo para los futuros desarrolladores del programa. Para esto se hizo una división en módulos como se mencionó anteriormente y se realizó una documentación detallada que incluye una serie de diagramas de bloques tratando de mostrar qué archivos de código pertenecían a cada módulo de los que planteamos. Pero viendo que estos diagramas resultaron un tanto complejos y tan solo brindaban una mirada superficial a la estructura, se realizaron tablas de referencias cruzadas en Excel que mostraban las funciones y las variables que relacionaban cada uno de los archivos de código del programa. Con el uso de estas dos herramientas, resulta más sencillo tomar una decisión a la hora de alterar el código.

Figura 18. Forma principal PCSIM RELOADED

51

Después de muchas versiones modificadas de PCSIM, algunas que no lograron los objetivos buscados, otras que daban peores resultados que la original y otras que dejaron de funcionar casi por completo, se logró obtener una versión que propone un mejor manejo de la memoria y aunque el módulo que se alteró no es muy significativo, se puede ver claramente la reducción en el consumo de memoria que presenta el programa.

Figura 19. Forma Principal PCSIM RELOADED con objetos.

52

Comparando la Figura 18 con la Figura 19, se puede apreciar que al cargar los objetos correspondientes a la Memoria Caché, la Unidad de Periféricos, la ventana de Otros Pines, y la ventana de Créditos, la carga en memoria debido a la creación de estos objetos aumenta el consumo de memoria RAM, mostrando así que los objetos anteriormente no estaban creados en la RAM del computador.

53

10. COSTOS

RECURSOS HUMANOS HORAS x PERSONA VALOR HORA TOTAL

Director del Proyecto 20 semanas * 2h $40.000 $1.600.000 Asesor 20 semanas * 2h $30.000 $1.200.000

Desarrolladores 20 semanas * 30h *

2 $5.000 $6.000.000

TOTAL RECURSOS HUMANOS $8.800.00

0

EQUIPO CANTIDAD VALOR

UNIDAD TOTAL Computador en alquiler 1 $600000 $600.000

TOTAL EQUIPO $600.000

LICENCIAS DE SOFTWARE CANTIDAD VALOR

UNIDAD TOTAL DELPHI 6 1 $3000000 $3.000.000

TOTAL LICENCIAS DE SOFTWARE $3.000.00

0

PAPELERÍA CANTIDAD VALOR

UNIDAD TOTAL Papel 2 * 500 hojas $8.000 $16.000

Fotocopias 1000 $50 $50.000 Encuadernación 1 $25.000 $25.000

Empaste 3 $4.000 $12.000 Cartucho 2 $90.000 $180.000 Disquetes 10 $1.500 $15.000

Discos Compactos 10 $1500 $15000 TOTAL PAPELERÍA $313.000

SERVICIO INTERNET CANTIDAD VALOR

UNIDAD TOTAL 007 MUNDO 4 Meses $28.000 $112.000 Marcaciones 4000 $80.07 $320.280

TOTAL SERVICIOS INTERNET $600.280

COSTOS INDIRECTOS CANTIDAD VALOR

UNIDAD TOTAL Energía 2000 horas $161 $322.000

Transporte 1200 viajes $1000 $1.200.000

TOTAL COSTOS INDIRECTOS $1.282.00

0

OTROS CANTIDAD VALOR

UNIDAD TOTAL Imprevistos - - $380.000

TOTAL OTROS $380.000

TOTAL COSTOS $14.985.2

80

54

11. PROBLEMAS EN EL DESARROLLO DEL TRABAJO DE GRADO Una de las dificultades de este proyecto fue la falta de una documentación unificada y clara a lo largo del código, que fue precisamente uno de los problemas que originó el presente trabajo de grado. PCSIM es un proyecto desarrollado por diferentes grupos, y cada cual basándose en lo desarrollado por los grupos anteriores. Esto implica que cada grupo programó de una manera diferente, y así mismo cada uno tuvo una forma de documentar diferente, acomodada a los propios intereses de cada grupo. Esto hizo que la inversión de tiempo comprendiendo el código fuera mucho mayor a la prevista en un principio. Otra de las dificultades más claras es la gran extensión del código, ya que PCSIM es un programa que se ha desarrollado en varios trabajos de grado anteriores y tiene muchas líneas de código, tanto que ha llegado al punto de colapsar. Esto hace demasiado largo el proceso de comprensión del código. Finalmente se presento un retraso debido a la falta de experiencia en DELPHI, en lenguajes de programación orientados a objetos y la dificultad para obtener información respecto al tema.

55

12. POSIBLES CAMBIOS EN UNA FUTURA VERSIÓN. Además de las sugerencias consignadas en anteriores trabajos de grado por los anteriores desarrolladores de PCSIM, como la inclusión de barra de estado y manejo de “TOOL TIPS”, la manipulación de la memoria de microprograma y la integración de periféricos y mejoras del procesador con microprogramación, se sugiere revisar el archivo de ayuda, ya que es el archivo de mayor tamaño dentro de los archivos del simulador, su tamaño no es justificado ya que ni siquiera cuenta con una tabla de contenido ni con un motor de búsqueda, lo que hace que la ayuda de PCSIM sea difícil de manejar para los usuarios. Se recomienda generar para dicho archivo la tabla de contenido y un índice temático similar a los usados por los programas comúnmente, para que el usuario pueda hacer uso de la ayuda con facilidad y familiaridad. Este trabajo de grado deja claro la manera cómo se deben trabajar las formas y los objetos. Se debe seguir revisando el código para lograr una mayor optimización y esto se puede hacer por cada módulo en los que se dividió el programa. Consideramos que es la forma mas sencilla que encontramos para hacerlo. Depende de la habilidad del grupo si pueden encargarse de modificar uno o mas módulos.

56

13. CONCLUSIONES Este capítulo muestra las conclusiones del estudio orientadas hacia la parte metodológica del trabajo de grado. • Se sentó un precedente respecto al tema de desarrollo de herramientas

pedagógicas, dejando presente que es necesario planear el proyecto con una clara visión de futuro y prever los cambios y la evolución que pueda sufrir dicho proyecto.

• La planeación de las actividades del proyecto y junto con ella la elaboración de

un cronograma objetivo y preciso, es vital para un riguroso desarrollo del proyecto en cuestión.

• Es preciso realizar una selección adecuada de la información disponible para

evitar retrasos en el cronograma y obtener los resultados deseados. • La documentación de todos los procesos y resultados obtenidos, es vital para

que el desarrollo del proyecto no se detenga ni se retrase, al contrario, facilita un proceso continuo y eficiente.

• Se señaló una metodología adecuada para abordar un problema donde se

involucran innumerables aspectos y variables, y así mismo la necesidad de tener el criterio correcto para tomar ciertas decisiones que afectan el desarrollo de un proyecto.

57

14. BIBLIOGRAFÍA HERBER, Jens. El gran libro de DELPHI 2 : curso intensivo, practica, técnicas profesionales, bases de datos, multimedia. Barcelona : Marcombo, 1997. ANDERSON, Loy. DELPHI in depth. Berkeley, California : Osborne McGraw-Hill, 1996. ROMERO, Ana Maria; TREJOS, Jairo Andrés. Simulador didáctico de un procesador PCSIM IV (Unidad de Control Microprogramada). Pontificia Universidad Javeriana, 2003. BOADA, Gerardo Alberto; CALDERON, Javier Leonardo. Simulador de un procesador PCSIM (Unidad de Control microprogramada verticalmente). Pontificia Universidad Javeriana, 2003 CREACIÓN DE COMPONENTES EN DELPHI http://www.el-hacker.com/foro/index.php/topic,1786.0.html DELPHI IN A NUTSHELL. Chapter 2: The Delphi Object Model. http://www.oreilly.com/catalog/delphi/chapter/ch02.html SOFTWARE ENGINEERING II : Delphi language details. http://flinflon.brandonu.ca/Dueck/1997/62368/tobject.html FONTE, Gerard. Software Documentation. Nuts & Volts. Vol 24. No5. May 2003. Pag 98- 101 R. Hernandez. Metodología de la investigación, México, McGraw-Hill, c2003. 3a ED.

58

ANEXOS EN CD-ROM

ANEXO A. DIAGRAMAS DE BLOQUES

• Unidades Comunes • Unidades Memoria • Unidades Periféricos • Unidades ALU • Unidades CACHE • Unidades DMA • Unidades Procesador sin Segmentar • Unidades Procesador Segmentado y Predictor de Bifurcaciones • Unidades Diagramas de Tiempo

ANEXO B. TABLAS DE REFERENCIAS CRUZADAS

• Unidades Comunes

• Unidades Memoria

• Unidades Periféricos

• Unidades ALU

• Unidades CACHE

• Unidades DMA

• Unidades Procesador sin Segmentar • Unidades Procesador Segmentado y Predictor de Bifurcaciones

• Unidades Diagramas de Tiempo

59