Los Quads, nuestro proximo objetivo… Hola amigos, otra semana mas que transcurre y poco a poco nos acercamos al final del curso, aunque todavía no se ha avanzado lo que se esperaba en la construcción del micro-C, pero tenemos la confianza en Dios, que todo saldrá bien. Recién la semana pasada, les comentamos que comenzamos a diseñar los Quads para la generación del código intermedio, sin duda, ésta será una labor muy ardua, ya que hay que considerar una gran cantidad de situaciones que podrían darse, durante la traducción del programa. Entre esas situaciones podríamos mencionar: Declaración de variables, definición de funciones, especialmente las recursivas, que aunque tenemos una idea de como representarlas en el stack frame todavía dicha idea no nos convence en lo absoluto, entre otras de las cuales estaremos platicando seguramente en los próximos días. Hablemos del caso especial de una función, la estrategia que tenemos pensado seguir, es que cuando el parser detecte que existe una definición de una función, nosotros procedamos a realizar las tareas que sean necesarias para reservar el espacio requerido en el stack para dicha función: como crear el stack frame, reservar espacio para las variables locales, no incluímos la reservación de espacio para los argumentos pasados a la función ya que éstos se almacenaran en el espacio del invocador, etc. En este apartado, nos entra la fuerte duda sobre cómo funcionaría esto en el caso particular de las funciones recursivas, ya que como todos sabemos, cada función recursiva debe de tener creado su propio stack frame, para que se pueda preservar el valor de cada una de sus variables en el ámbito que corresponda. Entonces, si nosotros pensamos dedicar solo una porción del stack para la función, al momento en que se realice el auto-llamado, la función invocada sustituiría los valores de las variables de la función invocadora, entonces es evidente, por lo menos desde nuestro punto de vista, de que se tiene que crear otro stack frame para la función invocada. Pero el problema es que no sabemos cuantas veces se llamará a si misma la función, como para reservar ese espacio de antemano, por lo que todavía no esta claro como vamos a ir creando los stack frames conforme la función se vaya auto-llamando. En cuanto a la declaración de las variables, estamos de acuerdo, de que por cada variable int o char, se reservaran 4 bytes en el stack frame, al mismo tiempo que se almacenara en la tabla de símbolos el offset respectivo para cada variable. En cuando a la asignación indizada, por los momentos no nos preocuparemos, ya que a nosotros nos tocó el statement repeat-until. Por cada ítem que les acabo de mencionar, haremos un Quad para cada caso. Además, haremos Quads para la traducción de statements como while, if, repeat-until, printf, scanf. Por los momentos ya tenemos creadas varias clases, las cuales detallamos a continuación: cQuad: Representa un quad, en el AST. Y sus atributos son: private int operador; private int operando1; private int operando2; private Object result; Tenemos una clase, exclusivamente diseñada para la representación de cada operador que esté involucrado en un Quad en el AST. La clase es cOperatorQuad. La cual esta compuesta de una serie de atributos estáticos de tipo entero, los cuales describirán a través de su nombre el fin para el cual serán utilizados. Dichos atributos serán utilizados, para ser seteados en el campo operador de la clase cQuad que recién les mostramos. Además, también tenemos una clase llamada cRegistrosT, la cual representaran cada uno de los 10 registros, $t0 … $t9, de MIPS, los cuales serán utilizados para la carga de variables locales y temporales, en la ejecución de los programas. A través de dicha clase se realizara la asignacion y liberación de cada uno de estos registros. Esto es todo por hoy, ha sido un placer comunicarles el estado de avance del compilador micro-C. Que tengan un buen día! Saludos!