domingo, octubre 30, 2005

 

El primer disque compilador de mi existencia

Primer experimento generando código, gran cosa no es, pero emociona... es como decir que estas construyendo un carro y ver juntas por primera vez las cuatro ruedas(pegadas al chasis, correctamente), aunque haga falta todo el resto, ya tienes una plataforma que se mueve...

Asi se siente poner en marcha un pequeno compilador de sumas para mips. bueno, spim... (ni es lo mismo ni es igual)

Eso me recuerda que cuando inicie mis estudios, mi papá me preguntó que como era que los ceros y unos se convertian en un programa, y como era que la computadora los hace funcionar.
Hasta ahora, cuatro años después podría decirle una respuesta...

Para iniciar, recuerdan el ejemplo minimal? pues, bien, utilicé el archivo minimal.lex, y modifiqué minimal.cup.

package Ejemplos;

import java_cup.runtime.*;
import java.util.LinkedList;

parser code {:
public static void main(String args[]) throws Exception {
new parser(new Yylex(System.in)).parse();
}
:}

action code {:

private boolean[] usoReg = new boolean[8];

private String getFreeReg(){
for(int i = 0; i < i =" (int)(reg.charAt(2)" nreg =" getFreeReg();" result =" new" reg =" nReg;" result =" new" reg =" T.reg;" nreg =" getFreeReg();" result =" new" reg =" nReg;" result =" new" reg =" F.reg;" nreg =" getFreeReg();" result =" new" reg =" nReg;" style="font-family:georgia;">La parte de la gramática es igual que el ejemplo en clase, salvo unas pequeñas modificaciones.
aca lo interesante es la funciopn para tomar un registro y para liberarlo. No son nada del otro mundo vdd?

Dado este código de cup, generando, compilando y corriendo, se abre la consola, donde hay que escribir la cadena de sumas y multiplicaciones, terminados con puntoycoma, aqui pueden ver el ejemplo de corrida:

----------------------------
2+3*8+6*9*5;
li $t0 , 2
li $t1 , 3
li $t2 , 8
mul $t3 , $t1 , $t2
#queda libre $t1(1
#queda libre $t2(2
add $t1 , $t0 , $t3
#queda libre $t0(0
#queda libre $t3(3
li $t0 , 6
li $t2 , 9
mul $t3 , $t0 , $t2
#queda libre $t0(0
#queda libre $t2(2
li $t0 , 5
mul $t2 , $t3 , $t0
#queda libre $t3(3
#queda libre $t0(0
add $t0 , $t1 , $t2
#queda libre $t1(1
#queda libre $t2(2
#se escribe el resultado
li $v0, 1
add $a0, $zero, $t0
syscall
terminamos?
------------------------ '
otro ejemplo:
------------------------
3*9*2*4*5;
li $t0 , 3
li $t1 , 9
mul $t2 , $t0 , $t1
#queda libre $t0(0
#queda libre $t1(1
li $t0 , 2
mul $t1 , $t2 , $t0
#queda libre $t2(2
#queda libre $t0(0
li $t0 , 4
mul $t2 , $t1 , $t0
#queda libre $t1(1
#queda libre $t0(0
li $t0 , 5
mul $t1 , $t2 , $t0
#queda libre $t2(2
#queda libre $t0(0
#se escribe el resultado
li $v0, 1
add $a0, $zero, $t1
syscall
#terminamos?

----------------------
Como es obvio, falta la parte de las directivas y todo ese rollo... por los momentos mis pruebas las hice mediante copy-paste. Con ver que el resultado correcto se desplegara en la consola, me bastaba.

Claro, que no salio a la primera, en varios intentos, mi codogo salia escrito con errores de sintaxis, pero eso es naturalmente debido a la falta de práctica con MIPS.

 

Una Hashtable con múltiples objetos bajo la misma llave


En mi proyecto, la tabla de símbolos está implementada mediante una tabla hash que contiene objetos entre cuyos campos están el nombre y el ámbito. La llave de dichos objetos se calcula entonces concatenando el valor del ámbito, cuatro puntos (“::”) y el valor del nombre.

Esto tiene la ventaja de que rápidamente se puede averiguar si existe ya un identificador con un nombre dado en el ámbito especificado, pues basta con calcular la llave y preguntarle a la Hashtable mediante el método containsKey. La dificultad que esto me propuso, era el problema de cómo recuperar TODOS los identificadores dado un ámbito, i.e. dado el nombre de una función o procedimiento, recuperar tanto parámetros como variables locales.

Primero, y para no hacer un recorrido estilo Programación 1 en busca de todas las instancias cuyo campo ámbito correspondiera, quise averiguar si hay una forma de que la tabla hash pudiese mapear una sola llave a varios objetos. Aun no se si se puede, pero javadoc dice que “el nuevo valor asociado reemplaza al valor anterior”. Busqué dentro del mismo javadoc a ver si existe otra estructura capaz de hacer el trabajo; la búsqueda fue infructuosa. Ya sin ideas, pregunté a compañeros y profesores. La mayoría me sugiere que cree mi propia clase, y un compañero me sugirió que usara una tabla hash por ámbito en la cual guardase tablas hash por nombre.

Lo primero es: combinar esas dos sugerencias. Creo que funcionaría, pero me complicaría los procedimientos de inserción y búsqueda de símbolos, que ya está programada y probada.

Decidí hacer lo siguiente: 1) Mantener mi tabla de símbolos tal y como está hasta ahora. 2) Agregar una segunda tabla hash, donde las llaves son ámbitos y los valores son LinkedList que apuntan a los mismos objetos que están en la tabla original.

De esa forma, la lista de los identificadores pertenecientes a un ámbito está “siempre lista y servida para llevar”.

Ya realicé los primeros ensayos. La inserción en ambas tablas se hace sin problemas, y aunque para terminar de hacer útil esa segunda tabla de símbolos hace falta un par de adiciones, ya se ve que cumple los objetivos.

El principal uso que pretendo darle es principalmente para comprobar los tipos de los parámetros en las llamadas a funciones, Aunque aun no estoy 100% seguro de cómo hacer eso... jeje.


martes, octubre 25, 2005

 

Assembler en MIPS

Primero que nada, mis disculpas por la entrega tardía. La excusa la dejo a la imaginación.

Comentarios generales:

El laboratorio fue fácil de hacer, las dificultades, como siempre aparecen haciendo más interesante el rollo.

Instalé la versión que venia en el CD que encontré en el parqueo, eso no dio problemas.

Luego, copiar el codigo del ejemplo de suma, pues valla! esta vez copié bien!!!. La carga se hizo bien, probé y funcionó.

Hasta aquí todo bien, el problema fue que suspendi el laboratorio y lo retome hasta el lunes en la noche.

Para ser honestos, mejor ví algunos blogs de los compañeros, y lógico, mi codigo no salio tan diferente, asi que solo voy a relatar algunas cosas que por lo menos no estaban en los blogs que YO VI.

1. para ahorrarme el error de escribir mal $zero, aprendi a usar la y move. tambien escribo menos .

2. aprendi a usar jal, porque mi programa ejecutava en ciertas ocasiones "tanto el if como el else", entonces decidi usar jal para tirar la ejecucion hasta despues del "cuerpo del else".

3. Quise usar las cadenas directamente en la instruccion, sin usar cadn, pero no halle el modo, si es que existe.

4. No se como funciona el modo de ejecucion por pasos, ya que le coloco cualquier numero de pasos en la caja correspondiente pero no veo que pase nada, no veo que cambien los registros, asi que, me conformé con verlos mientras el programita "esperaba el entero"

Comentarios finales

El Assembler de MIPS es para mí {mucho}* más fácil que el de Intel. Con sólo ver el codigo de suma, sabía por donde "iba la cosa". Me dió por revisar uno de los viejos ejemplos de cuando cursé "Organizacion de Computadoras" o "Diseño Lógico Digital"(no recuerdo cual es cual, deberían llamarse las dos del mismo modo, con I y II como todas las demás), y no se que dice ahi. (asembler de intel...)

Hacerle las modificaciones al código no fue difícil, excepto por que si se comete un error el simulador no lo informa como solemos estar acustumbrados, y hay que rebuscar un poquito pero "eso se lima con el uso".

Una vez más, lamento lo escueto del contenido de la clase antes mencionada, ya que el asunto del ensamblador es sumamente interesante, no tanto a nivel de programaciónes sencillas, sino a nivel de análisis como en las llamadas de procedimientos(que no he visto en detalle pero se que estan en "el apendice", y habría sido macanudo tener una clase en hondureño al respecto. Eso lo digo porqeu siempre que busco algo en Internet , me pierdo y termino averiguando otra cosa que nada tiene relacionado con lo que incialmente buscaba.

domingo, octubre 16, 2005

 

Electivas?

En respuetsta a la pregunta ¿Qué curso optativo me gustaría recibir en la carrera de Ingeniería de Sistemas y por qué?...
Se me hace una pregunta difícil, pues en lo personal creo en la diversificación del conocimiento como un arma sumamente poderosa, especialmente en un mundo globalizado, donde se requiere no solo de una amplia gama de conocimientos, sino también de la capacidad para relacionarlos en formas nuevas para lograr el avance, y sacar de su estancamiento a países como el nuestro.
Por otro lado, también creo en el autoaprendizaje, sobre todo como principal fuente de diversidad de conocimientos.
En ese sentido, es mi opinión, que un curso electivo debe tener una relación no obvia con la carrera, pero no puede en definitiva ser un tópico aislado totalmente. Creo que debe ser una tipo de conocimiento práctico relacionado con el desempeño real que un graduado de la carrera de Sistemas Computacionales de Unitec debería tener dentro del sector laboral-industrial hondureño.
Todo esto, para concluir, que me agradaría incuir como parte de mi formación en Unitec, una clase en la que se nos enseñe a formar parte de, y a dirigir grupos de personal multidisciplinario, y convertirlos en auténticos equipos de trabajo. No sé como podría llamarse una clase como esa, y si llegase a existir en Unitec, espero que no le pongan un nombre indecente ni demasiado "inflado".
Tal preferencia surge de la observación más inquietante que he realizado desde que formo parte del conjunto cuasimisterioso, elitista, todopoderoso de estudiantes de Sistemas, la tremenda incapacidad que tenemos "los de sistemas" para comunicarnos entre nosotros, y con "los demás"; y solemos decir "los demás en un tono casi despectivo, como si nadie más en el mundo tiene conocimientos específicos de SU carrera de los cuales la gran mayoría son ignorantes, lo cual porsupuesto, nos incluye también a "nosotros".
Esa forma elitista de ver el mundo de la cual pecamos la mayoría de los estudiantes de sistemas (para no mencionar a los docentes y profesionales del área) es una fuerte barrera que en muchos casos impide aprovechar de manera óptima el conocimiento y habilidades de las personas cuya preparación es distinta de la nusestra. Debo aclarar que no me refiero solamente a la preparación académica, pues "no hay mejor escuela que la experiencia", y de allí que en el mundo de los negocios haya triunfado tanto "analfabeta".
Existe una fuerte tendencia del alumno de sistemas de reinventar la rueda,especialmente a la hora de llevar a cabo proyectos que simulan software empresarial, donde "nos toca inventar como hacerlo" porque "no entendemos lo que nos ha dicho el cliente".
Es por eso que mi eleccion sería en definitiva, un curso en el cual se nos preparase la mente para aprender "como llevarnos con los demás" en el sentido productivo de la frase, porque, en conformidad con la idea de "profesionales capaces de desarrollar y transformar empresas", podría ser que sea la carrera de sistemas la más débil, porque a diferencia de Mercadotecnia, Publicidad o Turismo, de las cuales en casos hasta nos atrevemos a hecer burla, y a quienes se les ha enseñado por concepto a estudiar a la gente como fuente de negocios, a nosotros se nos ha enseñado a estudiar las ciencias de la computación en uno de los sentidos más mecanicistas, casi olvidando que el propósito de la máquina es el hombre, no al revés.
Digo todo esto, porque e las clases de la carrera en las que que habla de la gente, del cliente -que dicho sea de paso son pocas- , se trata al "usuario" como si se tratase de un ser disminuido en capacidades, y encontrando incluso textos formales que hacen referencia al usuario como si fuese un tonto de cuyas faltas es necesario protegerse, olvidando a veces por completo la naturaleza humana que caracteriza todas y cada una de nuestras obras.
En resumen, y luego de esta crítica que aseguro, está basada en mí mismo y en mis más cercanos compañeros, reitero que me gustaría que tratásemos en curso formal y bastante de cerca, la psicología, el comportamiento humano, la comunicación y las relaciones interpersonales, a fin de lograr el mejor provecho de las personas que han optado por una rama del conocimiento distinta, para saber como colaborar con ellos, para poder interactuar mejor con y como gerentes de empresas.
Y solo para sellar, y no quedar en contradicho con mi afirmación a cerca del autoaprendizaje, me permito recordar, que si bien esas ramas de conocimiento arriba mencionadas, pueden fácilmente buscarse y encontrarse en lecturas abundantes, son también áreas de conocimiento bastante extensas, y que un curso debe tener la intención de mostrarnos qué aprender, para no perder el norte.

This page is powered by Blogger. Isn't yours?