Modelado y verificación de hardware usando tipos abstractos de datos

Texto completo

(1)M  V́  H U T A  D. . J P C F. U D L A F D Iı́ D  Iı́  S  C́ B́ D. C., C 2009.

(2) M  V́  H U T A  D. . J P C F. T  P    ı́  I  S  C́ D  I. S V. V P M.S.. U D L A F D Iı́ D  Iı́  S  C́ B́ D. C., C 2009.

(3) Agradecimientos “Having made pleasure and pain, gain and loss, victory and defeat the same, engage thou in the battle for the sake of battle; thus thou shalt not incur sin.” B.G, II-38. Cualquier extensión de papel se queda corta para enumerar las obras que por mi han hecho tantas personas a lo largo de todo mi proceso formativo y, de un modo mas general, mi proceso como individuo. Pero, viéndome obligado en este texto a resaltar a los actores por cuyo influjo he visto facilitada mi transformación y crecimiento en toda la variedad de las dimensiones de la experiencia humana, he de recordar con inmensa gratitud a: Mis padres, Clemencia y Carlos, creo que es obvia la razón que explica porque están enumerados acá. Recuerdo a mis padrinos y a Judith con especial afecto, gracias a ellos vivı́ mi destino comprendiendo que los momentos buenos y/o malos son solo momentos. A los que considero mis mentores la Ing. Claudia Jiménez, el Ing. Rafaél Gómez y el Ing. Rafaél Garcı́a, quienes me ofrecieron su valioso apoyo y experiencia tanto desde el contexto de la academia y el arte de la docencia como desde los aspectos mas humanos del dı́a a dı́a universitario. A mis excelentı́simos amigos, Diego Mejı́a, Javier Riascos y Carlos Saavedra, adalides de la continua búsqueda por la virtud y pacientes conocedores de mi carácter acérrimo. A la Ing. Sonia Vivas y el Ing. Mauricio Guerrero, quienes facilitaron los procesos para que fuese posible plasmar las ideas contenidas en este trabajo.. .

(4) .

(5) Índice general 1. Introducción 1.1. Finalidad del proyecto . . . . . . . . . . . . . . . . . . . . . . . 1.2. ¿Cómo leer este documento? . . . . . . . . . . . . . . . . . . . . 2. Marco teórico 2.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Relevancia del problema . . . . . . . . . . . . 2.1.2. Contexto especı́fico del proyecto . . . . . . . . 2.2. Reescritura y modelado con Tipos Abstractos de Datos 2.2.1. Tipos Abstractos de Datos . . . . . . . . . . . 2.2.2. Lógica de reescritura . . . . . . . . . . . . . . 2.3. Maude: Interpretación de TADs . . . . . . . . . . . . 2.3.1. Módulos . . . . . . . . . . . . . . . . . . . . 2.4. Procesador PDUA . . . . . . . . . . . . . . . . . . . . 2.4.1. Organización del PDUA . . . . . . . . . . . . 2.4.2. Interfaz de programación (ISA) . . . . . . . . 3. Desarrollo del proyecto 3.1. Descripción del proyecto . . 3.1.1. Objetivos . . . . . . 3.2. Proceso de desarrollo . . . . 3.2.1. Modelado del PDUA. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 4. Consideraciones finales 4.1. Resultados . . . . . . . . . . . . . . . . . 4.2. Conclusiones . . . . . . . . . . . . . . . 4.3. Trabajo futuro . . . . . . . . . . . . . . . 4.3.1. Con respecto al modelo del PDUA . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 1 2 3 4 5 6 9 11 11 20 27 28 32 33 38. . . . . . . . . . . .. . . . . . . . . . . .. . . . .. 39 . . . . 39 . . . . 39 . . . . 40 . . . . 40. . . . .. 51 . . . . 51 . . . . 52 . . . . 53 . . . . 53.

(6) ÍNDICE GENERAL. 4.3.2. Con respecto a la metodologı́a en general . . . . . . . . ..  53. A. Instruction Set Architecture. 54. B. Semántica de los componentes del PDUA. 61. C. BNF del modelo *. 63.

(7) Capı́tulo 1 Introducción La verificación es un camino abierto y de aplicación a una gran variedad de problemas que puede ir mas allá del lugar común de la ingenierı́a o la arquitectura de software. Es bueno pensar que gracias a la existencia de ciertas ideas capaces de ser aplicadas a una variedad tan grande de problemas, la solución a preguntas en las áreas en donde estos problemas surgen es facilitada de manera importante y con implicaciones profundas en el alcance de las respuestas que se quieren obtener. En el caso de la metodologı́a y las herramientas presentadas a lo largo de este trabajo, no solo se tiene a la mano el andamiaje de construcciones abstractas para explicar los fenómenos a estudiar de una manera “estática” o “inerte”. Se provee, junto con la teorı́a formal, un interpretador para hacer realidad la posibilidad de acotar, usando un enfoque de búsqueda mecanizada sobre la potencia de cálculo de las máquinas contemporáneas, el problema de garantizar las propiedades de una realidad modelable. Sin embargo, se debe andar con cierta cautela y comprender que, aunque se tienen tanto las orientaciones teóricas como las dimensiones prácticas para enfrentarse los problemas que surgen en varias áreas del conocimiento, no se puede hacer un uso indiscriminado de estas. Los métodos ofrecidos en este trabajo son extensibles a otros problemas que se presentan, pero no a todos. No todos los problemas formulables se prestan para el uso adecuado de la reescritura ni para la descripción de un lenguaje declarativo 1.

(8) 1.1. FINALIDAD DEL PROYECTO. 2. interpretado como el presentado acá. Se requiere de una sensibilidad formada por la comprensión madura de las posibilidades de un lenguaje para tomar la decisión de usarlo como herramienta para solucionar un problema en un contexto dado. Uno de los propósitos manifiestos de este proyecto consiste en entender de que manera podrı́an serle útiles a otras áreas del conocimiento los temas formales que se estudian comúnmente dentro de la teorı́a de la computación.. 1.1.. Finalidad del proyecto. El proyecto consiste en el desarrollo de una metodologı́a para atacar el problema de la verificación de hardware aprovechando construcciones conceptuales desarrolladas en el área de las matemáticas. Adicionalmente, se usarán herramientas para hacer posible la computación de las interpretaciones hechas usando estas contracciones dentro del objetivo de la corrección de hardware. El trabajo entonces consistirá en: 1. Entender el bagaje teórico que fundamenta la construcción del prototipo. 2. Hacer una introducción al problema de la verificación en lo concerniente a la corrección del hardware. 3. Introducir al lector en el método usado durante el desarrollo de este proyecto para concebir el hardware como una entidad abstracta y por ende sujeta a ser verificada. 4. Exponer brevemente la forma en la cual se hicieron los planteamientos para esbozar el prototipo del hardware estudiado. Como conclusión, se hará un recuento sobre las experiencias adquiridas en el transcurso de este desarrollo..

(9) 1.2. ¿CÓMO LEER ESTE DOCUMENTO?. 1.2.. 3. ¿Cómo leer este documento?. El documento se compone de tres bloques cuya pertinencia sirve a la utilidad de los propósitos buscados. Los temas se dan de la siguiente manera: 1. Un marco teórico que busca iniciar se manera ligera a los posibles lectores que el tema de este documento atraiga. La simplicidad del material no indica que sea del todo fácil de comprender, pues por momentos se usa terminologı́a que puede resultar foránea a las nociones y conceptos conocidos por el lector. 2. Una descripción del proyecto que se extiende sobre los aspectos generales y particulares del proyecto sin intentar profundizar mas allá en los detalles que no añaden valor alguno para entender que se esta haciendo con el hardware y de manera especı́fica con el prototipo. 3. Una sección final de conclusiones y trabajo futuro, cuyo sentido dentro de los lineamientos enunciados en esta introducción es el de servir como guı́a para aquellos que estén interesados en seguir cultivando la propuesta que aquı́ se expone..

(10) Capı́tulo 2 Marco teórico Es el propósito de este capı́tulo el exponer los conceptos matemáticos y otros conceptos relacionados únicamente con los sistemas digitales sobre los que se fundamenta el desarrollo de este proyecto. Se intentará durante toda la exposición ser conciso en la extensión del andamiaje conceptual que se quiere estructurar. Esto se debe a que las materias a tocar son bastante amplias y por ende muchos de los alcances de las teorı́as en cuestión no son de utilidad para los objetivos del proyecto. No obstante, el lector deberá tener cautela al leer este marco teórico, dado que es necesario conocer una variedad de nociones básicas en los rudimentos de las matemáticas discretas y los sistemas digitales para entender el sentido de la existencia de los temas tratados dentro del alcance de este trabajo. Se advierte lo anterior porque, si se hubiese tenido en mente hacer una exposición detallada y profusa en tecnicismos y notaciones, el público al cual va dirigido este documento no podrı́a formarse una idea a priori de manera rápida y efectiva acerca de las bases fundamentales sobre las que se ha desplegado el presente trabajo. En la construcción de las secciones subsiguientes, se hará énfasis en contextualizar al lector en los aspectos prácticos que rodean la construcción del modelo. Se desea también ubicar claramente al lector en la problemática a la cual estos desarrollos buscan encontrar una solución o un paradigma sobre el cual comprender la naturaleza de los problemas que se están tratando. El lector deberá comprender que no es el interés de esta sección el sentar conocimientos originales, y que, por el contrario, busca reafirmar y canalizar la comprensión previa de las materias expuestas. Para una reflexión con profundidad 4.

(11) 2.1. MOTIVACIÓN. 5. sobre los temas de este capı́tulo, invitamos a continuar la exposición presente en los trabajos de los autores referidos en la bibliografı́a.. 2.1.. Motivación. La concepción de sistemas compuestos de partes que buscan solucionar un problema o simplemente intentar describir un fenómeno esta sujeta la falibilidad. Esta caracterı́stica de los sistemas surge en el momento en que la descripción de estos empieza a requerir de la modularización de sus partes con el propósito de emular un comportamiento a partir de la composición de los comportamientos mas simples de estas. La idea de concebir por partes o dividir para entender esta sujeta a la capacidad del modelador para comprender el comportamiento de la totalidad como una correlación de comportamientos mas simples. Esto conlleva un riesgo: entre mas subdivisiones existen en un modelo la posibilidad de fallos aumenta de manera importante si se pierde de vista la función y la razón de la existencia de estas. Dada la magnitud actual de los sistemas con los cuales se trata a diario, medida en términos de las funcionalidades ofrecidas, son muy pocos aquellos lo suficientemente simples para poder ser analizados con facilidad y comprendidos de manera efectiva. Surge ası́ la necesidad de automatizar la verificación. Esta es, sin embargo, una medida que deberı́a ser tomada como última instancia dentro de cualquier proceso de abstracción. El problema mas grande consiste, como se habı́a anotado previamente, en la magnitud, y a este se añade la necesidad de conseguir una solución al problema a la mayor brevedad. Todo lo expuesto confluye entonces a varios problema prácticos, del cual se escogió para este trabajo el verificar el hardware. El hardware, si se concibe como un problema de esta ı́ndole, posee todas las caracterı́sticas antes descritas: Es altamente modularizado en términos de las funciones de sus partes y su organización. Los módulos usados desde un punto de vista lógico están fuertemente jerarquizados..

(12) 2.1. MOTIVACIÓN. 6. Los módulos mas pequeños del hardware (compuertas lógicas y otros) están perfectamente comprendidos desde un punto de vista lógico. La composición de estos módulos a medida que crece el tamaño de los prototipos aumenta proporcionalmente con la complejidad del comportamiento que estos deben implementar. El hardware, añadiendo a lo dicho anteriormente, esta sujeto a fallos no solamente en su concepción lógica sino también en su concepción fı́sica. Estos fallos tendrán eventualmente injerencia sobre la seguridad de las ejecuciones que se espera sean fiables.. 2.1.1.. Relevancia del problema. El problema fundamental sobre el cual este proyecto de grado quiere esbozar una solución es la corrección de software. Pero no se habla acá de software construido con formalismos y estructurado en bloques con una semántica compleja en el sentido de la extensión de una posible expresión de esta semántica usando teorı́as axiomáticas tales como el cálculo de Hoare. Tampoco se quiere dar la idea al lector de que la especificación responde al modelado de un problema donde los elementos de los conjuntos a partir de los cuales se componen los estados tienen mas significado que el de ser un sı́mbolo binario o un operador tı́pico de operaciones aritméticas u otros conjuntos de cardinalidad pequeña. El modelo pretendido no reposa sobre otra semántica mas allá de la que se puede dar él mismo. El sentido de lo anterior se comprende si se tiene en perspectiva que un lenguaje como GCL1 da sentido a su ejecución basado en otra semántica simbólica de mas “bajo nivel” que vendrı́a a ser la teorı́a de conjuntos y las construcciones algebraicas de las matemáticas. Otro ejemplo formulable podrı́a ser cualquier compilador de un lenguaje imperativo. A modo de sentar un ejemplo tomemos a C++. Este lenguaje posee construcciones que permiten concebir los conceptos tı́picos del paradı́gma de Orientación 1. Ver segunda parte “The Semantics of a Small Language” en [Gri81]. En esta parte del libro se construye un lenguaje de programación imperativo interpretando y denotando de manera adecuada ciertos predicados que describen un problema dado..

(13) 2.1. MOTIVACIÓN. 7. a Objetos, y, a la vista del programador, el “universo” sobre el que construye su solución tiene que estar concebido de la manera en como C++2 entiende (e implementa) el paradigma en cuestión. El común de los ejemplos expuestos es el absoluto reposo de las ideas que las máquinas abstractas desean expresar sobre la semántica operacional de las máquinas concretas, y, mas aún, el como estas no tendrı́an mas utilidad que la de ser juegos de ideas incapaces de poder calcular si no se pueden plantear sus construcciones en términos de construcciones fı́sicas mas sencillas y efectivamente implementables. Ahora, por un momento considérese el hardware como si este fuese un software en el sentido de poder ser expresado axiomáticamente. ¿Como se traducirı́a (en el mundo de lo fı́sicamente implementable) el hardware a algo mas sencillo que él mismo?. Se podrı́a considerar el expresar todas las construcciones existentes en el ISA3 por su interfaz dadas como axiomas (usando precondiciones y postcondiciones) y formulando (¿habrı́a la necesidad?) ciertos cálculos para entender la semántica de programas mas complejos. En todo caso, cualquier especificación que se pueda hacer sobre el hardware adolecerı́a de la capacidad de ser implementado por otra semántica (que evidentemente debe ser efectivamente calculable) de mas bajo nivel. Esta es una de las raı́ces del asunto que se desea tratar en este trabajo: El hardware mismo propone el significado de sus operaciones, ası́ como muchas otras cosas en el mundo fı́sico (por ejemplo, un grifo o una cisterna). Las implicaciones en el mundo del software “macroscópico” sobre el que se construyen abstracciones con semánticas mas elaboradas y para el cual ya existen herramientas (por ejemplo los lenguajes de tercera generación), es que si este depende de construcciones dentro de otros sistemas de un nivel inferior de abstracción, necesariamente los comportamientos de estos últimos sistemas afectarán de manera aleatoria en frecuencia e impredecible en magnitud a la semántica completa del sistema que se pretende implementar. Para aclarar lo que se entiende aquı́ por magnitud se debe observar que, en 2. [Fav03] discute la interpretación de CPP como un lenguaje de programación. Este es un ejemplo del planteamiento de un paradigma en términos de construcciones ya establecidas. 3 Instruction Set Architecture. Ver [Tan99] para una explicación detallada de la clasificación por niveles de una máquina..

(14) 2.1. MOTIVACIÓN. 8. el mundo fı́sico de la ejecución de un programa, el cambio de un estado en un dispositivo electrónico modifica la representación simbólica que se esta computando sobre él. Las consecuencias pueden ser tan pequeñas o tan grandes como lo puedan ser en la translación de este estado a las construcciones de alto nivel que las están llevando a cabo. El otro aspecto que se expondrá es la discusión acerca del proceso de diseño y fabricación de las máquinas puesto que este no es tan preciso como para pretender que no existen errores (de formulación lógica o de implementación fı́sica) al final del desarrollo del producto. Naturalmente es bastante costoso que estos errores salgan a producción; lo que sı́ debe ser evitado es que los dispositivos diseñados para la venta al público tengan errores peligrosos para la integridad fı́sica de los bienes o la vida de las personas. Como ejemplo de estos hechos, hemos de recordar4 los sucesos acaecidos en febrero de 1998 con la familia de procesadores IntelTM Pentium ProTM . Para ser concisos, el problema consistı́a en una mala ubicación de ciertas constantes que determinaban segmentos de memoria causando eventualmente fallas en los manipuladores de modos de administración de bajo nivel, y, lo mas importante a resaltar, las fallas pueden ser “de consecuencias catastróficas”, en sı́ntesis, un cambio muy pequeño en una constante puede causar problemas que afectan la fiabilidad y/o confiabilidad del sistema. Estos hechos no son casos aislados, en 1997 se encontró otro error5 en el IntelTM Pentium IITM que causarı́a problemas aritméticos similares a los que hicieron fallar al tristemente celebre cohete Ariane 56 .. 4. Ver [Col98]. Ver [Dan]. 6 Ver [Lio96]. 5.

(15) 2.1. MOTIVACIÓN. 2.1.2.. 9. Contexto especı́fico del proyecto. La múltiple variedad de funcionalidades que ofrece el hardware contemporáneo exige que la complejidad de este, medida en términos de la cantidad e interrelación de los componentes fı́sicos y su organización para expresar el comportamiento que se espera, sea bastante alta. Como consecuencia de este hecho es difı́cil hacer un análisis detenido para entender en total detalle el comportamiento de un dispositivo de complejidad estructural considerable. Llegado un punto, es tal la variedad de componentes en un hardware y tan compleja su interrelación, que se debe recurrir a la modularidad y a la estrategia de “dividir y vencer” para poder abstraerse lo suficiente en aras de que el problema de diseño sea soluble. Como corolario de lo dicho, se afirma que entre mas alta la abstracción, las partes ya no se conciben como tales: empiezan a tomar la forma de operaciones de un nivel mas alto, módulos fı́sicos que implementan composiciones de módulos mas pequeños. Dada la extensión de las arquitecturas que pudieron haber sido escogidas, se decidió buscar una arquitectura bastante pequeña, lo suficiente como para que fuese entendida rápidamente. El procesador que se estudió, y del cual el presente trabajo hace ejemplo para sentar la metodologı́a de análisis que propone, es el PDUA7 . Este procesador esta pensado para servir a los propósitos didácticos de ciertos cursos de microelectrónica ofrecidos por el departamento de Ingenierı́a Eléctrica y Electrónica de la Universidad de los Andes. Como se habı́a expresado previamente, el procesador se da su propio comportamiento y su organización le da el significado a sus operaciones. El problema ahora consiste en intentar abstraer las propiedades de este a partir de su organización fı́sica y simularlas para lograr demostrar la existencia o inexistencia de fallas. La abstracción de las propiedades de la máquina se representó usando Tipos Abstractos de Datos. Este formalismo conforma un andamiaje conceptual con fundaciones sólidas en teorı́as como la reescritura de términos y otros para atacar el problema de la verificación. 7. Aporte dado gracias al profesor Mauricio Guerrero. Ver [Gue08].

(16) 2.1. MOTIVACIÓN. 10. El problema de la simulación consiste en encontrar alguna manera de evaluar los formalismos expresados en la abstracción creada de tal modo que pueda constatarse si el funcionamiento de esta cumple con la especificación dada. Particularmente, es interesante que exista una herramienta con una sintaxis parecida a la del formalismo y que, mas aún, esta exprese y evalúe aserciones sobre las propiedades modeladas. Esta herramienta es Maude..

(17) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 2.2.. 11. Reescritura y modelado con Tipos Abstractos de Datos. La teorı́a sobre el cual se hizo la abstracción de las propiedades del PDUA es el modelado con Tipos Abstractos de Datos (en adelante se denominarán TADs) y reescritura. La función que estas dos herramientas proveen consiste en facilitar el acotar el conjunto de estados posibles contenidos en cualquier ejecución del PDUA, o de cualquier otro sistema cuyas propiedades relevantes puedan ser expresadas dentro de la sintaxis de estas.. 2.2.1.. Tipos Abstractos de Datos. ¿Qué es un TAD? Para entrar a definir con claridad que es un TAD, es necesario comprender el concepto de Estructura Computacional. Definición 1 Una Estructura Computacional o EC (también llamada Tipo Concreto), es un conjunto de datos junto con ciertos algoritmos para operar sobre ellos8 . Cuando un problema es formulable en términos de transformaciones de sus caracterı́sticas cuantificables, sus soluciones son susceptibles de ser procesadas simbólicamente por una Estructura Computacional adecuada, de tal manera que es posible obtener, a partir de un conjunto de datos pertinentes al problema, resultados útiles dentro del contexto de este. Una estructura computacional comprenderı́a entonces un conjunto de elementos dentro del contexto del problema y un conjunto de operaciones relevantes a este expresadas en términos de una máquina abstracta, por ejemplo, un lenguaje imperativo. En este sentido, una estructura computacional serı́a una instancia de una denotación de un nivel mas alto capaz de ser interpretada de varias maneras, tantas como lenguajes con la potencia de una máquina de Turing sea posible concebir. Lo anterior requiere entonces que los datos y/o caracterı́sticas sobre las cuales el modelo formulado puede hablar de sus estados sean codificables. Este punto 8. Ver [Car91] en la sección 6.3.

(18) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 12. será ampliado posteriormente en la discusión sobre términos9 . Ahora, como se señaló previamente, una EC es solamente una implementación de un modelo abstracto. Este modelo abstracto debe poseer entonces la capacidad de expresar los elementos relevantes de una realidad abstraı́da y también servir como esquema inicial sobre el cual hallar soluciones útiles y traducibles a un lenguaje algorı́tmico. Los TADs permitirán representar tanto los sı́mbolos que cuantificarán las caracterı́sticas observables como sus interrelaciones, que dan al modelo la capacidad de emular la realidad referida al problema. Definición 2 Un Tipo Abstracto de Datos es una estructura algebraica que abstrae una EC. Consta de un conjunto (llamado tipo de interés) junto con un conjunto de operaciones relevantes a sus elementos. Los TADs permiten entonces servir de conducto formal sobre el cual se puede generar un modelo del problema. Se explicará a continuación de que manera es posible transcribir la comprensión de un problema a este formalismo, y se ponderara sobre las razones por las cuales esta transcripción es útil. Denotación de modelos usando TADs Previamente se habı́a establecido la necesidad de plantear los problemas como un álgebra con un número adecuado de operaciones que poseen una semántica relevante a la búsqueda de una solución. También se hacı́a explı́cita la necesidad de hacer que estas operaciones fuesen expresables, y que esta denotación reflejase todo aquello que deberı́a quedar manifiesto sobre el contexto de la solución. Los contextos sobre los cuales los problemas surgen tienen algunas caracterı́sticas discernibles sobre el conjunto total de sus propiedades cuantificables, y es, para el propósito de encontrar una solución, necesario que estas caracterı́sticas tengan magnitudes operables de manera algebraica. Es por este motivo que los TADs deben construirse sobre conjuntos de elementos discernibles al que se le deben anexar operaciones sobre la totalidad de los elementos que los componen. 9. Ver la definición 11..

(19) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 13. Definición 3 Un TAD Parámetro es un conjunto ya definido de TADs que permiten construir elementos del TAD del cual hacen parte y cuyo conjunto de operaciones y su semántica permite construir la semántica de las operaciones de este. Se define entonces la denotación para un TAD: T AD Y[X]. (2.1). Y es el nombre del TAD. X es un conjunto de TADs ya definidos. El conjunto X es, como se definió con anterioridad, una composición de varios TADs. Dado que se esta construyendo una semántica nueva, es necesario que esta esté basada en operaciones más sencillas sobre otros TADs. Se dice entonces que es necesario concebir la noción de TAD primitivo, que puede ser algún conjunto común del cual se conoce su composición y como se calcula sobre las operaciones ya definidas en él. Este conjunto podrı́a ser N o B o algún otro que cumpla con las caracterı́sticas solicitadas y que además permita codificar los conjuntos relevantes dentro del modelo sobre el cual el problema se presenta. Generalmente los TADs primitivos se consideran como dados dentro la notación y por ende no se incluyen explı́citamente en esta. Nace entonces la necesidad de expresar las operaciones sobre las cuales se puede hablar de la riqueza operativa del modelo explicado.. Denotación genérica de las operaciones En el mundo de los TADs, toda la expresividad esta basada en el uso de funciones. Incluso las constantes dentro de otros conjuntos (por ejemplo Z) se entienden en el contexto de los TADs como funciones cuyo dominio es ..

(20) 14. 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. Definición 4 La denotación común de una operación en un TAD es:. f : Ym × Xf → Z. (2.2). Y es el TAD. m es la multiplicidad del TAD. Un producto cartesiano de m conjuntos. Z es un TAD parámetro. X f es un producto cartesiano de TADs parámetro. A partir de esta denotación genérica, se procede entonces a construir todas las operaciones. Funciones Iniciales Las funciones iniciales tienen la responsabilidad de construir los nombres de los elementos sobre los cuales van a operar las demás funciones de los TADs. Definición 5 La signatura de las funciones iniciales es: i : Xi → Y. (2.3). Y es el TAD. Xi es un producto cartesiano que se construye a partir de los TADs parámetro. Este conjunto puede estar vacı́o, y, en este caso, las funciones iniciales se entenderı́an como constantes dentro del lenguaje del TAD. Funciones Constructoras La signatura de las funciones constructoras contiene a los productos cartesianos de los elementos del TAD en cuestión. Estas funciones deben construir los elementos del TAD, es decir, con estas funciones debe ser posible hablar de todos los elementos que componen las caracterı́sticas cuantificables relevantes al problema de las cuales ya se habı́a hecho explı́cita su necesidad. Definición 6 La signatura de las funciones constructoras es: c : Y m × Xc → Y. (2.4).

(21) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 15. Y es el TAD en el cual se esta construyendo. m es la multiplicidad del producto cartesiano de Y. X c es un conjunto de TADs parámetro. Al hablar de la construcción de los nombres de los objetos del TAD, se requiere dentro de esta teorı́a el introducir la noción de construcción por inducción. Este tema será tratado posteriormente dentro de esta sección. Un problema importante de la construcción de los elementos del TAD es que estos deben ser únicos y, esta concepción de unicidad debe reflejar la unicidad misma de los elementos discernibles dentro del contexto del problema. Funciones Simplificadoras Se entiende por función simplificadora a una expresión cuyo propósito es reducir la longitud de la cadena que expresa al objeto nombrado a su expresión “mas simple”, o irreducible dentro de lo que se entiende por esta noción que será explicada en la definición 11. Definición 7 La signatura de una función simplificadora es: s : Y m × Xs → Y. (2.5). Y es el TAD en el cual se esta construyendo X s es un producto cartesiano de conjuntos de TADs parámetro. Funciones Analizadoras Una función analizadora provee a la baterı́a de funciones del TAD la posibilidad de observar los elementos de este bajo la óptica de una funcionalidad especı́fica que el modelo debe poseer. Definición 8 La signatura de una función analizadora es: a : Y m × Xa → Z Y es el TAD en el cual se esta construyendo. X a es un producto cartesiano de conjuntos de TADs parámetro. Z que puede ser un TAD parámetro o un elemento del TAD Y.. (2.6).

(22) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 16. Retomando el tema de la discernibilidad de los elementos de los TADs, es perentorio dejar por sentado que dos elementos de un TAD son diferentes si y solo si son discernibles por las funciones analizadoras, es decir, al ser reducidos a su forma canónica, las analizadoras obtienen términos10 sintácticamente diferentes. Definiciones inductivas Las funciones constructoras deben sentar su funcionalidad sobre la base de métodos de construcción de nombres creados previamente. Los modelos TAD y la concepción de esta metodologı́a de especificación descansa entonces sobre el principio de inducción matemática y, desde este punto de vista, es un método de especificación que como tal basa toda su expresión algebraica y el cálculo sobre sus elementos (las constantes o los nombres de los elementos) usando descripciones inductivas. Las implicaciones de esta concepción de la verificación es que el comportamiento que el TAD esquematiza es operable solo por medio de cálculos sobre operaciones que están definidas usando métodos de inducción matemática. De este modo, tanto los elementos del mundo como las operaciones que se dan sobre ellos se definen usando cadenas decrecientes finitas. Definición 9 El tipo de interés11 de un TAD es un conjunto que esta definido de manera inductiva. El conjunto mas simple es uno que solo contiene o constantes (funciones del TAD de aridad 0) o que contiene funciones iniciales aplicadas sobre uno o mas parámetros del TAD. Este conjunto se denota ası́: Y0 = {⊥} ∪ {i(x) | i ∈ I, x ∈ Xi }. (2.7). ⊥ sirve como elemento indefinido, es “polimórfico” en el sentido de pertenecer a todo TAD definible y cuyo uso es aplicable cuando no sea posible calcular efectivamente una función de un TAD, o, en otras palabras, nombrar el objeto dentro dentro del contexto del mundo que el TAD intenta abstraer. Teniendo el conjunto de elementos básicos definidos, o el tipo de interés, se procede ahora a denotar el conjunto de los elementos construibles para nombrar todos los elementos del TAD. 10 11. Ver la definición 11. Ver [Car91]..

(23) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 17. Definición 10 El conjunto de nombres12 es definido de inductivamente ası́: Yk+1 = Yk ∪ {c(y, x) | c ∈ C, y ∈ (Yk \ {⊥})m(c) , x ∈ X c }, para k ≥ 0. (2.8). Nótese que ⊥ no hace parte de Y. La función encargada de construir los nombres de los objetos mas complejos es c ∈ C, donde C es el conjunto de funciones constructoras, y como tal, toma elementos tanto del TAD en cuestión como de algunos de los TADs parámetro. Todo el tipo de interés Y se denotarı́a ası́: [ Y= Yk. (2.9). k≥0. Con este tipo de interés y las funciones del TAD, se puede entonces describir de manera algebraica el comportamiento del mundo. Construcción a partir de funciones 13 Los elementos de un TAD parten de las definiciones inductivas que determinan su forma. Como en toda definición inductiva, se requiere de uno o varios elementos especiales desde los cual se pueden construir los nuevos elementos. Estos elementos deben cumplir con las siguientes caracterı́sticas: Estos elementos deben tener un nombre autodenotativo y solamente serán equivalentes a sı́ mismos. Este elemento debe pertenecer al TAD. Este elemento no puede ser construido a partir de cualquier otro elemento del TAD. Cualquier otro elemento del TAD debe estar construido a partir de alguno de estos elementos. Los demás elementos se pueden obtener a partir de combinaciones de la aplicación de las funciones constructoras sobre los elementos del tipo de interés.. 12 13. Ver [Car91] Las definiciones contenidas en esta sección hacen parte del material [Car91].

(24) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 18. Definición 11 Un término es una unidad sintáctica del lenguaje que simboliza una magnitud referente al problema en cuestión. Los términos son clasificados de esta manera: Términos atómicos Este tipo de términos se categoriza de esta manera: Constantes primitivas Son los elementos que componen a un TAD parámetro. Como ejemplos tenemos 0 ∈ Z o ’a’ en un conjunto de caracteres. Variables Son términos que toman valores de un tipo según el contexto en el cual se encuentren. Elemento indefinido ⊥. Término compuesto Definición 12 Un término compuesto es una cadena de sı́mbolos de la forma f (t1 , t2 , . . . , tr ). es primitivo si pertenece al TAD parámetro. es no-primitivo si pertenece al TAD sobre el cual se esta construyendo. El tipo del término es el codominio de la función que lo construye, y, si alguno de sus argumentos es ⊥, el término es equivalente a ⊥. Término condicional Los términos condicionales tienen un valor que depende de la valuación de un término de tipo B. Se denotan ası́:    Z si c =true. t=  Z 0 de lo contrario. Se debe notar que c ∈ B ..

(25) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 19. Axiomas Los axiomas son el medio por el cual se construyen las relaciones algebraicas entre los elementos del TAD y sus parámetros. Estos axiomas son el cuerpo de las signaturas y determinan la forma en como se calculan y se operan los elementos del TAD. Los axiomas se describen ası́: < lado izquierdo > = < lado derecho >. (2.10). donde el lado izquierdo es un término compuesto no primitivo sin términos condicionales y el lado derecho puede ser cualquier término dentro del conjunto de los que pueden ser nombrados por el TAD. Lema de forma normal 14 Este lema delimita con claridad como debe ser la sintaxis de los elementos de un tipo de interés dado. Definición 13 Todos los elementos definidos en el tipo de interés Y son de una de las formas: i(x) c(x, y) Donde i es una función inicializadora y c es una función constructora. La función inicializadora debe estar evaluada en una tupla de los TADs parámetro y la constructora debe estar evaluada también en la misma tupla y otras tuplas del T AD Y. Como se puede ver, Lema de forma normal deja en claro la naturaleza inductiva de los tipos de interés.. 14. [Car91].

(26) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 2.2.2.. 20. Lógica de reescritura. Por la naturaleza misma del proyecto, que es la descripción de un sistema de operación secuencial en pasos discretos, es debe existir alguna manera de comprender las propiedades (tales como propiedades de seguridad o propiedades de vivacidad)15 que controlan la operación de dispositivos de esta categorı́a. Se entiende entonces que verificar tal sistema requiere de la formalización de esta secuencialidad de tal modo que sea posible emitir aserciones sobre las propiedades que debe cumplir el comportamiento modelado. La lógica de reescritura concibe un esquema sobre el cual proyectar los factores inherentes del comportamiento de un sistema secuencial a una formalización en la cual ya existen métodos para decidir sobre la validez de una afirmación expresada dentro de la sintaxis de esta. La traslación de una especificación al dominio de la lógica de reescritura hace que las propiedades de esta sean consideradas dentro de su nueva interpretación como reglas de deducción. Estas reglas de deducción son un aspecto fundamental que hace posible la utilización de esta lógica para el propósito buscado en este proyecto. Nociones básicas Una vez introducida la razón por la cual es útil la lógica de reescritura dentro de este proyecto, es necesario para proseguir con la exposición el hacer una presentación somera de las nociones necesarias para comprender posteriormente el interpretador Maude, su utilidad y como encajan conjuntamente el prototipo con las facilidades que este lenguaje provee16 . En secciones previas se habı́a expuesto el sentido de la construcción de los elementos sobre los cuales otro conjunto de operaciones constituirı́an el modelo que representara fielmente las propiedades útiles a la solución. 15. seguridad: “nada malo pasa”, vivacidad: “eventualmente algo bueno pasa”. Estas propiedades son introducidas en [Car]. 16 Esta sección esta basada en la teorı́a desarrollada en la referencia [Asp91].

(27) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 21. Signaturas Las estructuras llamadas signaturas son una versión generalizada de nuestra idea previa sobre la construcción de los TADs a partir de conjuntos de sı́mbolos. Es necesario definir esta estructura porque el concepto de traslación de estados dentro de la lógica que se esta exponiendo requiere que sea posible nombrar a estas traslaciones y clasificarlas en categorı́as. En esta definición se considera un conjunto S cuyos elementos (sı́mbolos para nuestro contexto) denominaremos sorts. Añadimos además que S ∗ \ λ es el conjunto de palabras finitas que se pueden construir con los sı́mbolos de S y sus elementos se denotan como tuplas ordenadas. Definición 14 Una Signatura es: Un conjunto S ,. de sorts.. Un conjunto R que contiene sı́mbolos de relación. Un conjunto F que contiene sı́mbolos de función. Todos los elementos contenidos en F ∪ R tienen asignado un tipo de sort, lo que se dirı́a formalmente ası́: t : F ∪ R −→ S ∗ Se le dice constante a los sı́mbolos de función que cumplen con f (e) ∈ S . Esta definición de signatura es interpretable de manera inmediata en el mundo de los TADs. Las funciones iniciales en un TAD corresponden dentro del esquema de las signatura a un conjunto de sı́mbolos de función que estarı́an ubicados en S . Los sorts y los elementos construibles a partir de ellos pueden ser clasificados en diferentes conjuntos que particionan a S ∗ . Estas clases de equivalencia se denominan kinds. Pertenecer a la misma clase de equivalencia implica que al menos una de las operaciones existentes definidas para un sort es compartida por todos los demás de su clase de equivalencia..

(28) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 22. Operadores Un operador es una función calculable que en el contexto de los TADs corresponderı́a a aquellas funciones que modelan un comportamiento interesante dentro del modelo. Los operadores permiten construir los términos con los cuales los conjuntos pueden ser denotados por extensión, de manera que cada uno de los elementos que se espera que estos conjuntos tengan sea nombrado. Reglas condicionales e incondicionales Las teorı́as de reescritura poseen signaturas, pero, además de estas formas con las que se nombran los elementos del modelo, coexisten otros objetos que le dan a la teorı́a la posibilidad de articular el comportamiento usando los elementos de una signatura dada. Se tenı́a previsto que para este proyecto era necesario usar una teorı́a con construcciones que permitiesen hablar de máquinas de estado. La teorı́a de reescritura posee tres tipos de declaraciones que cumplen con la satisfacción de nuestras necesidades: ecuaciones, membresı́as y reglas.6 Ecuaciones La formulación de comportamientos requiere que sea posible plantear de alguna manera los mecanismos por los cuales estos, una vez denotados, puedan ser evaluables de manera efectiva y significativa en el contexto de las máquinas de estado. Por este motivo, requerimos precisar que es necesario encontrar un cálculo para evaluar las expresiones construibles dentro de las signaturas y, en consecuencia, darle el comportamiento buscado a los elementos de esta para que emulen la realidad modelada como se supone que debe hacerlo. La propuesta dentro de las teorı́as de reescritura es el uso de la sustitución de iguales por iguales en ecuaciones cuyas variables están tipadas haciendo posible el cálculo. En esta propuesta se habla de sustitución en un sentido análogo al sentido de sustitución en los axiomas definidos para los TADs. Para explicar este concepto, supongamos que tenemos dos funciones relacionadas por la ecuación g(t) = h(t). Ambos lados de la ecuación tienen el mismo tipo, de tal manera que esta ecuación no presenta ambigüedad alguna con respecto.

(29) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 23. la posibilidad de reemplazar las instanciaciones de alguno de los dos lados en otra expresión diferente de la teorı́a, es decir, ambas expresiones son equivalentes en todo el ámbito de la teorı́a donde están formuladas. En la exposición sobre la forma en la que son nombrados los elementos de los TADs usando los principios de inducción matemática, un mismo elemento puede tener dos nombres sintácticamente distintos. Si se escoge entonces una tupla de constantes (o términos) cuyos tipos correspondan a los tipos de los argumentos que uno de los lados de la ecuación poseen, y la instancia que forman es valedera y cumple con el lema de forma normal del TAD en cuestión, se puede hacer la sustitución de un lado de la ecuación por el otro aplicando al elemento sustituyente los valores de la tupla. Entonces: g(t)|t:=k ∈ Σ/g (2.11) h(t)|t:=k El sı́mbolo Σ/g denota el conjunto de términos en la signatura que son instancias de g(t) y k es una lista de términos. Reglas Las reglas dentro de la teorı́a de reescritura sirven para describir el aspecto dinámico dentro de un sistema. Esta descripción es posible porque las reglas tienen la capacidad de emular máquinas con transiciones si se hace la interpretación del concepto de término al concepto de estado y del concepto de transición al concepto de reescritura. Anteriormente se hacia énfasis acerca de la necesidad de un cálculo con la posibilidad de definir y evaluar la validez de ciertas aserciones que además deberı́a poseer una aplicación dentro del contexto del problema referido. Como esbozo de ese cálculo, se expondrá una versión de un solo sort (dado que la generalización de las reglas de deducción se aplica a particiones de un conjunto de sorts generadas por las ecuaciones aplicables a los elementos de este conjunto)..

(30) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 24. Reglas incondicionales Una regla es una sentencia r : t → t0 donde t y t0 son términos pertenecientes a una signatura Σ y r es el nombre de la regla. Se dice que para una teorı́a de reescritura R t → t0 es una R-reescritura si y solo si el sı́mbolo t0 se puede obtener de t usando estas las siguientes reglas de deducción17 .. 1. Reflexividad: Un término es reescritura de sı́ mismo. t → t0 2. Congruencia: Si se tiene un conjunto de reglas es posible aplicar a los términos de estas una función f . t1 → t10 . . . tn → tn0 f (t1 ) → f (t10 ) . . . f (tn ) → f (tn0 ) 3. Sustitución: Las reglas valen aún si se hace una sustitución textual σ p, donde p es una tupla de términos del tipo del sort legalmente sustituibles en la expresión. t1 → t10 . . . tn → tn0 σ p(t1 ) → σ p(t10 ) . . . σ p(tn ) → σ p(tn0 ) 4. Transitividad: Para t1 , t2 y t3 vale t1 → t2 t2 → t3 t1 → t3 Reglas condicionales Una regla condicional cumple con las mismas caracterı́sticas que se esperan de una regla incondicional, solo que, a diferencia de estas, las reglas condicionales son aplicables si y solo si un predicado evaluado sobre los términos de la expresión a ser deducida vale. Se concluye entonces que las reglas incondicionales son un caso especial de las reglas condicionales. El uso de estas reglas dentro de la reescritura consiste en abreviar la definición de las reglas reduciendo la cantidad necesaria de estas al momento de modelar la dinámica de un sistema discreto. 17. Ver el capı́tulo 4 en [Mes99].

(31) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 25. Coherencia La propiedad de la coherencia esta ı́ntimamente relacionada con el aspecto ya mencionado en el aparte sobre definiciones18 inductivas de los elementos de un sort. Dada la cantidad posible cadenas bien definidas que referencian un mismo elemento dentro de un conjunto construido usando los sı́mbolos de una signatura, es necesario garantizar de alguna manera que sea posible reescribir término expresado de forma compleja en un término equivalente dentro de la semántica que la signatura debe implementar. Esto es necesario porque los elementos describibles con la signatura deben poderse diferenciar entre sı́ y deben poderse operar entre ellos de acuerdo al comportamiento que deberı́an modelar. La definición que es necesario introducir en este momento es la de forma canónica. Forma canónica Al modelar una realidad se necesita poder diferenciar de manera explı́cita a los elementos aún si estos deben ser nombrados de formas diferentes con el propósito de ser calculables. Definición 15 Llamaremos forma canónica a un término t si, para un conjunto de cadenas bien formadas dentro de una teorı́a que buscan representar un mismo objeto dentro del modelo, una cadena de reducciones usando los axiomas dados siempre tiene a t como último paso. Dicho usando otras palabras, t es el último elemento de una cadena decreciente construida con los axiomas aplicables a los términos. En este sentido t es irreductible por la inexistencia dado que no se le puede aplicar algún axioma para simplificarlo. Las formas canónicas serán entonces los términos mas “pequeños” en el sentido de ser los elementos especiales de un conjunto inductivo19 y cualquier otra cadena equivalente a este término pertenece a su clase de equivalencia generada por los axiomas de la teorı́a. Si se cumple esta condición y los axiomas generan siempre cadenas finitas se dice que el conjunto de estos es terminante. 18 19. Ver definición 2.2.1 Ver sección 2.2.1..

(32) 2.2. REESCRITURA Y MODELADO CON TIPOS ABSTRACTOS DE DATOS. 26. Es necesario recalcar que las operaciones entre los elementos de las clases de equivalencia deben reflejar lo que se espera en la semántica de la realidad modelada, por ejemplo, en un modelo para N se debe cumplir que todos los términos que representan a 2 y 3 operen a alguna cadena válida que represente a 5 para una operación usual de adición dentro del conjunto modelado..

(33) 2.3. MAUDE: INTERPRETACIÓN DE TADS. 2.3.. 27. Maude: Interpretación de TADs. Maude20 es un lenguaje reflectivo que soporta lógica ecuacional y de reescri-. tura. Se ha venido desarrollando en el laboratorio de métodos formales y lenguajes declarativos de la Universidad de Illinois en Urbana-Champaign a lo largo de la última década como un esfuerzo conjunto con el SRI21 . Sus usos van dirigidos especialmente a la especificación declarativa de una gran variedad de sistemas que en apariencia pueden no tener similitud, pero que comparten semejanzas como la necesidad de ser modelados teniendo en cuenta su naturaleza concurrente. Como ejemplo de esta diversidad, Maude permite modelar sistemas biológicos, protocolos de encriptación y/o comunicaciones, y dentro del universo de problemas que tratan las ciencias de la computación, el modelado de la semántica de un lenguaje de programación. Debe decirse, no obstante, que este es un lenguaje de propósito especı́fico, y pese a que es tan potente como cualquier lenguaje imperativo moderno (los lenguajes imperativos pueden ser especificados en Maude), esto no implica queeste lenguaje sea apto para cualquier tipo de tarea. Maude facilita la solución de ciertos problemas si es posible que estos sean. mas fácilmente concebidos con las construcciones que este lenguaje provee y la lógica que permite ejecutar. No es apto, sin embargo, para aplicaciones intensivas de cálculo (piénsese en una multiplicación de un orden de magnitud de 106 de enteros usando un TAD escrito en la sintaxis Maude) pues la reescritura de los términos hace imposible que estas operaciones sean efectuadas de manera eficiente, muy por el contrario de un lenguaje imperativo sencillo como cualquier ensamblador, en donde las latencias son prácticamente las que la máquina se toma para poner los valores en los registros (tiempos del orden de ≈ 10−9 segundos)). Lo enunciado anteriormente con respecto a los TADs y la teorı́a de reescritura encuentra en Maude una forma de como una manera efectiva de hacer que los modelos se puedan convertir en prototipos ejecutables. De hecho, la virtud de Maude radica en que “fı́sicamente” emula una ejecución del modelo y, a medida que la ejecución se lleva a cabo, efectúa la evaluación de los estados contra una 20 21. maude.cs.uiuc.edu Stanford Research Institute, www.sri.com.

(34) 2.3. MAUDE: INTERPRETACIÓN DE TADS. 28. invariante establecida por el modelador. La sintaxis de Maude es una traducción bastante aproximada a la sintaxis de los TADs y las reglas de reescritura que habı́amos explicado previamente. Este documento no se extenderá mas allá de los ı́tems básicos necesarios para establecer un sı́mil que permita entender cómo se pueden traducir los TADs y las reglas a la sintaxis Maude. Se verá con mas detalle en el capı́tulo 3 la manera en como se aplican los conceptos expuestos en esta sección en el problema que trata este proyecto. Para detalles especı́ficos sobre la sintaxis del lenguaje el lector puede consultar el manual del lenguaje22 .. 2.3.1.. Módulos. Para organizar y separar los segmentos de una especificación en Maude de tal manera que esta tenga sentido para un ser humano, Maude propone la organización de esta bajo un esquema de módulos. Otra de las razones por las cuales esta separación es útil es el evitar la asignación de un mismo identificador a términos y expresiones diferentes y pertenecientes a partes no relacionadas semánticamente dentro de un modelo. Modos de inclusión 23. Por importación de módulos se entiende en el contexto de la reescritura y los TADs el añadir a una teorı́a (una signatura junto con los atributos ecuacionales de sus operadores además del conjunto de ecuaciones y membresı́as) otra ya preexistente para que conjuntamente construyan una teorı́a mas amplia en tipos y mas rica en operaciones según sea necesario. Ası́ que, cuando se hace la importación de un módulo, las operaciones y los sorts del modulo importado entran a hacer parte del módulo que las esta importando. Para efectos de conseguir lo anterior de una manera en la que no existan incoherencias con respecto a los identificadores tanto de los axiomas como de los sorts iniciales, Maude plantea tres modos de inclusión con los que se puede 22 23. Ver [Cla07]. Ver sección 6.1 en [Cla07]..

(35) 2.3. MAUDE: INTERPRETACIÓN DE TADS. 29. señalar al interpretador que tipo de restricciones existen sobre los identificadores en lo concerniente a su definición y la manera en la que se pueden usar en el módulo que los incluye. La inclusión de módulos es una operación que genera jerarquı́as de inclusión, que se mantienen a medida que se va anidando un módulo con respecto a los que están por encima de él. El modo de inclusión  ofrece al modelador la posibilidad de evitar que existan “colisiones” entre los nombres de los objetos, es decir, el impedir que existan dos términos compuestos que al ser reducidos usando la axiomática de módulo confundan dos elementos no equivalentes y, en consecuencia, confundiendo dos caracterı́sticas discernibles de la realidad que esta siendo modelada.. protecting. El otro aspecto que este modo de inclusión ofrece, es el evitar que se creen nuevos términos dentro del módulo importador con el tipo del módulo importado para los cuales no exista una ecuación que pueda reducirlos y operarlos con otros elementos de este último módulo. Es necesario señalar que Maude, aunque declara este modo, no tiene la capacidad de verificar en tiempo de ejecución si las condiciones enunciadas se están cumpliendo. Para ello, el staff de desarrollo de Maude tiene proyectos separados que crean herramientas como probadores de teoremas capaces de decidir este tipo de problemas24 . Acá se permite que hayan términos para los cuales no sea posible hacer una reducción usando ecuaciones del módulo del sort incluido, pero no se permite la existencia de nombres duplicados tal y como se explicó que no podı́a suceder en el modo protecting.. extending. including El modo de inclusión including, permite un libre uso de los nombres y las ecuaciones. Sin embargo, la inclusión mantiene el respeto por los modos de inclusión en la jerarquı́a de módulos de la cual el módulo importado hace uso. 24. Ver http://maude.cs.uiuc.edu/maude-tools.html.

(36) 2.3. MAUDE: INTERPRETACIÓN DE TADS. 30. Módulos funcionales y del sistema Los módulos son, recapitulando lo antes dicho, construcciones que permiten ordenar una especificación dada en módulos con propósitos diferentes a efectos de la comprensión del modelo. Maude tiene los dos tipos de módulos que enumera el titulo de esta sección. Módulos funcionales Los módulos funcionales sirven para escribir teorı́as ecuacionales como por ejemplo los TADs. Las componen las siguientes declaraciones: Nombre del módulo. Importación de otros módulos. El análogo en los TADs es la denotación de los parámetros. Declaración del nombre del sort o de los sorts que este módulo desea enunciar. Denotar la jerarquı́a de sorts entre los que se están importando y los que se acaban de crear. Se debe notar que todos los elementos de la jerarquı́a formaran un kind25 y que se tendrá por consecuencia que los nombres en el kind son operables con el conjunto de las operaciones del módulo mas alto en la jerarquı́a de importación. Declaración de las signaturas de las funciones con su respectiva aridad y atributos ecuacionales (por ejemplo, una función de aridad 0 que se entiende como identidad, o la conmutatividad de cierta operación binaria etc.). Declaración de las ecuaciones que permiten computar las funciones dadas. Estas funciones se plantean de manera inductiva como se explicó en 2.2.1. Las ecuaciones pueden ser condicionales. Membresı́as, que, condicionales o no, tienen la función de definir a que sort pertenece algún término cuando exista ambigüedad. 25. Ver [Cla07] para la definición de kind.

(37) 2.3. MAUDE: INTERPRETACIÓN DE TADS. 31. Módulos del sistema Los módulos funcionales son un caso especial de loas módulos del sistema. Los módulos del sistema añaden a los módulos funcionales la existencia de reglas tal y como se entienden dentro del tema ya tratado en la sección de teorı́a de reescritura. Para el interpretador Maude, aunque los módulos funcionales representan teorı́as ecuacionales donde la evaluación de un término consiste en aplicar los axiomas necesarios hasta reducirlo a su mı́nima expresión, estos módulos son tratados como si las ecuaciones representaran asignaciones. En otras palabras: el interpretador añade direccionalidad a las ecuaciones haciendo una traducción de las ecuaciones existentes en los módulos funcionales a reglas. El sentido teorı́as ecuacionales dentro de los módulos de sistema reside en que la evaluación de una ejecución de un conjunto de reglas puede dar como resultado en el transcurso de esta términos bastante extensos dificultando la ejecución en la máquina usada por el interpretador. La teorı́a ecuacional dentro de los módulos de sistema se aplica al hacer una transición donde su utilidad reside en disminuir al máximo la longitud de los términos. Estructuras paramétricas en Maude La exposición de la parametrización en Maude será breve pero contendrá lo necesario para entender su uso dentro del proyecto. Maude hace uso de dos tipos de construcciones necesarias para parametrizar los módulos: teorı́as y vistas. Una teorı́a es entendida como un conjunto de propiedades (tales como atributos ecuacionales) que debe poseer alguna estructura algebraica genérica. Lo anterior se puede interpretar si se tiene la idea de una abstracción que es implementada por una gran variedad de sistemas disı́miles, solo que esta abstracción en el presente caso corresponde a las propiedades algebraicas de un conjunto. Por ejemplo, las ideas de grupo, de anillo o semianillo pueden aplicarse indistintamente a varios contextos, y en ciertos casos ser bastante útiles dentro de una comprensión de la semántica de este. Una teorı́a cumple la función de abstraer propiedades. Estas propiedades serán proyectadas usando las vistas para hacer una interpretación de un módulo de tal manera que este adquiera las propiedades que la teorı́a especı́fica..

(38) 2.4. PROCESADOR PDUA. 2.4.. 32. Procesador PDUA. Al inicio del presente proyecto el enfoque buscado estaba bien delimitado. Se habı́a definido que se deseaba hacer (verificación de hardware) y solo bastaba encontrar un hardware útil para lograr el propósito del desarrollo de los métodos que se introducirán en el siguiente capı́tulo. Se evaluaron distintas opciones sobre una variedad dispositivos diversa para ser usados como fundamentos para el prototipo de este trabajo. Sin embargo, los dispositivos comerciales evaluados (procesadores ARMTM y otros como el ZilogTM Z80TM ) eran lo suficientemente complejos como para requerir un esfuerzo extensivo en tiempo, y en consecuencia, poco prácticos desde la óptica de los objetivos establecidos para este trabajo. En el transcurso de la etapa inicial del proyecto se contactó a un profesor del departamento de Ingenierı́a Electrónica, el ingeniero Mauricio Guerrero, quien apoyó el desarrollo del proyecto facilitando parte del material didáctico26 desarrollado por él y que esta dirigido a enseñar los rudimentos básicos de la microelectrónica a los estudiantes de pregrado para el uso dado acá. Los insumos para desarrollar este proyecto son los archivos de la descripción del comportamiento del procesador escritos en VHDL27 con los cuales es posible entender como se coordinan los módulos para computar y cuales son las funcionalidades que cada uno de estos ofrece para el propósito común del hardware. Las descripciones VHDL están organizadas para entender el comportamiento de cada uno de los fragmentos fı́sicamente independientes del PDUA. Cada fragmento describe el comportamiento dentro del sistema sin entrar en detalles sobre la implementación fı́sica de este. No obstante, se debe tener en cuenta que estas descripciones pueden ser implementadas fı́sicamente usando ciertas herramientas que interpretan este lenguaje y son capaces de modificar un circuito genérico para darle el comportamiento que estas proponen. 26 27. Ver [Gue08] VHSIC hardware description language..

(39) 2.4. PROCESADOR PDUA. 2.4.1.. 33. Organización del PDUA. El PDUA posee una organización sencilla y con los elementos mı́nimos que se requieren para implementar una máquina de acceso aleatorio28 . Posee una unidad de control, un banco de registros, la unidad operativa y otros dispositivos que controlan la interacción del PDUA con el mundo exterior. Los detalles sobre la semántica de los registros y otros aspectos necesarios para entender el PDUA están explicados con mas detalle en los anexos. Unidad de control La unidad de control efectúa la coordinación de las actividades de los otros fragmentos del dispositivo. Esta unidad implementa el siguiente ciclo29 : 1. Traer la siguiente instrucción de la memoria en el registro de instrucción. 2. Establecer el contador de programa a la siguiente instrucción. 3. Decodificar la instrucción. 4. Ejecutar la instrucción decodificada. 5. Iniciar el ciclo de nuevo. A este ciclo se le conoce comúnmente por el ciclo de fetch-execute-decode. En una máquina estructurada por niveles30 se distingue como el más bajo de estos a el de la lógica digital (compuertas, latches y otros dispositivos). Por encima de este nivel se posa la microarquitectura en donde ya se conciben módulos con un nivel de complejidad mas alto y cuya semántica operacional se asemeja mas a las operaciones tı́picas de N o B y también a la asignación. El último nivel en lo que concierne a este proyecto es el ISA 31 en el cual ya es distinguible la existencia de instrucciones de lenguajes de segunda generación. A estas instrucciones se les llamará opcodes. 28. Random Access Machine Ver capı́tulo 2 de[Tan99] 30 Ver capı́tulo 1 [Tan99] 31 Instruction Set Architecture 29.

(40) 2.4. PROCESADOR PDUA. 34. Nótese que para el proceso de decodificación de los opcodes se requiere que estos sean almacenados en un registro especial de instrucción al que no se puede acceder desde la interfaz de programación propuesta por el ISA. Cada opcode es por si mismo nombre de un microprograma que entra a ejecutarse posteriormente a la decodificación. La ejecución de los opcodes tiene su contador de microprograma propio (los tres bits menos significativos del opcode, que no son utilizados dentro de la codificación de estos) e indican en que paso de la microejecución se esta. Este contador de microprograma es útil, entre otras cosas, para ubicar a donde debe llegar un salto de microinstrucción en el caso de que el programa decida evaluar alguna de las banderas. Para poder inicial el ciclo de nuevo, la unidad de control debe definir cual es la siguiente instrucción que será ejecutada. Para ello hace uso de las banderas existentes en la ALU y toma la decisión basado en la instrucción en ejecución en caso de que esta sea una evaluación de salto, un llamado o un retorno. La unidad de control del PDUA también posee la capacidad de hacer un manejo de interrupción sencillo, que se lleva a cabo en el ciclo de ejecución básico. Unidad operativa La unidad operativa implementa 8 operaciones aritméticas y lógicas básicas: Suma con corrimiento, que al existir después de ser efectuada una operación activa la bandera respectiva. Las operaciones binarias usuales tales como disyunción exclusiva, conjunción y negación bit a bit. Complemento binario. Incremento en una unidad..

(41) 2.4. PROCESADOR PDUA. 35. Posee además las banderas mas sencillas necesarias para facilitar las computaciones básicas. Carry Bandera de corrimiento afectada siempre que exista un desborde en la última operación efectuada. Zero Activada siempre que el valor de la última operación sea cero. Parity Activada de acuerdo a la paridad de la cantidad de unos en la expresión binaria resultado de la última operación. Negative Esta bandera se activa cuando el bit mas significativo del resultado es negativo. Unidad de resolución de direcciones Su función es activar las lineas que permiten definir a que ubicación del espacio fı́sicamente direccionable debe dirigirse la próxima lectura o escritura efectuada por la máquina. Acá es necesario dejar en claro que este procesador usa un ancho de palabra de 8 bits y sus opcodes también están codificados empleando esta mismo cantidad de bits. Otra caracterı́stica relevante de esta máquina es que no hace diferencia alguna entre memoria de solo lectura o memoria de acceso aleatorio y tampoco efectúa una demarcación sobre los lı́mites de la pila. Es necesario que el programador defina como se hace este manejo directamente sobre el programa que esté desarrollando. Unidad de resolución de datos Esta unidad tiene la responsabilidad de controlar de donde entra o hacia donde se deberán dirigir los resultados de las operaciones ejecutadas por la unidad operativa. También define si el acceso que se va efectuar será de lectura o escritura según el opcode que se esta procesando. La redirección del estado de la unidad operativa puede hacerse o hacia el banco de registros (en este caso deberá estar seleccionado alguno de los registros no constantes), hacia la unidad de resolución de direcciones o en su defecto al puerto de entrada/salida de datos..

(42) 2.4. PROCESADOR PDUA. 36. Banco de registros Los registros que posee esta máquina son de propósito especı́fico y solo es ofrecido uno para la manipulación directa del programador usando la interfaz de programación dada. Solventando un poco esta situación, la interfaz de programación permite hacer asignaciones a un registro acumulador usando un movimiento entre registros, pero no una operación que directamente se refiera a este. Estas caracterı́sticas lo hacen muy rudimentario y dificultan mucho la programación, aunque se debe recordar que esta máquina es de propósito didáctico. PC: Es el contador de programa, y su valor corresponde a la ubicación en memoria en la que esta la instrucción que se esta efectuando en el ciclo de ejecución. ACC: Es el acumulador. Como se dijo previamente, este acumulador no es accesible por el usuario sino a través de una operación que use otro registro visible. El acumulador es uno de los operandos de la unidad operativa y por ende, siempre que sea necesario operar dos cadenas, una de estas dos debe ser el estado de ACC. A: Registro visible. CTE-1: es un registro que posee una constante para facilitar ciertas operaciones como el decremento usando caracterı́sticas básicas de la aritmética binaria. DPTR: Apuntador a datos. SP: Apuntador a la pila. TEMP: Registro de uso temporal para la ejecución de ciertos microprogramas. VI Constante que tiene la dirección en la memoria de la rutina que hace el manejo de la interrupción..

(43) 2.4. PROCESADOR PDUA. 37. Buses La noción básica de un bus es el ser una vı́a de comunicación entre distintas partes de un dispositivo electrónico para dar forma al datapath32 . En el PDUA existen tres buses: Bus A: Conecta al acumulador con la entrada de uno de los operandos de la unidad operativa. Este bus siempre esta activo y no se reasigna su estado a otro dispositivo diferente Bus B: Conecta al banco de registros con una entrada de la unidad operativa. La microinstrucción indica que registro es el que va a ser operado con el acumulador como el otro operando. Bus ALU: La señal de la ALU siempre esta activa sobre este registro. El otro extremo de este dispositivo es la unidad de resolución de datos. Bus C: Este bus interconecta a la unidad de resolución de datos junto con la unidad de resolución de memoria y el banco de registros. La decisión sobre quien toma el estado de este bus la hace el microprograma, y la unidad de resolución de datos es la que decide cual va a ser la fuente de la señal de este bus: la ALU o la señal de entrada que proviene de la memoria.. 32. Ver capı́tulo 1 [Tan99].

(44) 2.4. PROCESADOR PDUA. 2.4.2.. 38. Interfaz de programación (ISA). Naturalmente, por su objetivo didáctico, este procesador tiene un conjunto de instrucciones reducido y que se pretende sea extendido por los estudiantes. Posee un tipo de salto por bandera y un salto incondicional. Los tipos de direccionamiento ofrecidos son: Direccionamiento por registro: Se da entre un registro y otro del mismo tamaño. Direccionamiento directo: Este direccionamiento es el que se hace cuando se quiere asignar el valor de una posición constante de memoria a un registro. Direccionamiento inmediato: Consiste en asignar el valor de una constante directamente al registro. Las instrucciones son movimientos entre registros y una sola operación de adición, ya que las demás operaciones aritméticas lógicas están pensadas para ser extensiones desarrolladas por los estudiantes. El detalle de estas instrucciones se incluye como anexo a este trabajo.

(45) Capı́tulo 3 Desarrollo del proyecto El propósito de esta sección es enumerar varios aspectos del proyecto con el propósito de que el lector se forme un criterio acerca del alcance que adquirida.Esta sección estará entonces dedicada a exponer los procesos y resultados mas importantes.. 3.1.. Descripción del proyecto. El proyecto busca mostrar la manera de integrar las herramientas teóricas y conceptuales de verificación formal ya existentes e implementaciones sobre las cuales es posible efectuar simulaciones del comportamiento de un sistema para solucionar un problema relevante.. 3.1.1.. Objetivos. 1. Usar una herramienta de verificación de manera efectiva, entenderla y conocer sus bondades y limitaciones. 2. Comprender el PDUA desde la óptica de las matemáticas discretas. 3. Hacer un uso intensivo de los conceptos teóricos de los TADs para deconstruir los componentes de un hardware y modelar sus interacciones. 4. Explorar los alcances y limitaciones del enfoque teórico expuesto.. 39.

(46) 3.2. PROCESO DE DESARROLLO. 40. 5. Incorporar los conocimientos de dos campos diferentes (pero no opuestos) de la ingenierı́a en una aplicación concreta a una necesidad tecnológica.. 3.2.. Proceso de desarrollo. En esta sección se entrará a describir detalladamente la manera en la que el comportamiento del PDUA fue interpretado con el propósito de lograr una implementación que permitiese satisfacer los objetivos previamente enunciados. La propuesta que se profirió inicialmente consistı́a en formular el hardware de manera detallada en el sentido de plantear el modelo a través del uso intensivo de TADs para propósitos del modelado de los componentes fı́sicos. Lo anterior, en otras palabras, denota que la intención del proyecto, en términos del modelado, era generar una estructura de TADs en donde para cada componente fı́sico del hardware existiera un TAD y su correspondiente módulo Maude. Una vez logrado el propósito previamente evidenciado, se debe, para propósitos de verificación, modelar aserciones sobre el comportamiento de la máquina. Estas aserciones serı́an entonces evaluadas por el interpretador Maude en la medida en que este lleva a cabo la ejecución de la máquina.. 3.2.1.. Modelado del PDUA. Esta parte del documento busca ilustrar sobre el proceso de desarrollo y señalar la ruta a través del cual evolucionó la idea a medida que se tomaba conciencia sobre el problema a discutir. Se espera que al final de esta sección los interesados en seguir explorando esta idea posean un conocimiento mı́nimo para evitarles recorrer el mismo sendero, y por el contrario, facilitarles retomar las conclusiones aquı́ obtenidas de manera empı́rica para que de ellas puedan extender los métodos usados o proponer algo nuevo..

(47) 3.2. PROCESO DE DESARROLLO. 41. Especificación por TADs En el marco teórico ya se habı́a subrayado la potencia contenida en la lógica ecuacional para generar un discurso útil de la verificación de un sistema en el sentido de denotar por vı́as calculables de manera especı́fica la semántica de este. También se señaló esbozando de manera un tanto implı́cita la posibilidad de que el modelado usando TADs y teorı́as de reescritura sea aplicable en otras esferas del saber que ofrecen problemas bastante fértiles en lo referente a la aplicación práctica de las ideas aquı́ expuestas. Dicho lo anterior, primero se establecerá claramente cuales fueron las limitaciones encontradas en lo teórico desde la panorámica de los planteamientos hechos. Posteriormente, se procederá a mostrar un ejemplo práctico de un TAD y como se modeló un comportamiento que se supone cualquier ALU debe poseer. Terminada la exposición alusiva a los aspectos ecuacionales del modelado, se esbozará el papel que juega la teorı́a de reescritura dentro de la definición del modelo, ası́ como se manifestará el papel que esta teorı́a juega en los propósitos buscados por la verificación. Para concluir, se discutirán aspectos relativos a la implementación en la sintaxis de Maude del modelo planteado y la ejecución de la verificación en este. Comprensión del hardware: TADs Los TADs, como se expuso anteriormente, tienen la capacidad de modelar comportamiento. Se sugirió entonces que el comportamiento de un módulo puede ser denotado usando este marco conceptual. El otro aspecto resaltado en la motivación es que el hardware, aunque funcione como especificación formal en un lenguaje declarativo (por ejemplo VHDL) de una manera correcta según se ha definido la corrección para la semántica esperada, puede tener problemas en su implementación fı́sica. Para sentar un ejemplo visible dentro de la realidad práctica, algunos modelos IntelTM Core 2 DuoTM poseen ciertos defectos de fábrica1 que inutilizan uno de los dos núcleos que este procesador deberı́a tener operando según se ofrece al consumidor. IntelTM vende entonces estos procesadores defectuosos bajo la referencia Core 2 SoloTM , lo que indica 1. El lector puede profundizar con la referencia [sta08].