Archive for March, 2008
Cómo encontrar partes de Pigmeo sin terminar
He preparado un Custom Attribute para que los desarrolladores de Pigmeo puedan marcar métodos/funciones indicando que ese método aún no está implementado, debe ser reescrito o faltan cosas por hacer. Este método se utiliza en el desarrollo de Mono (aunque no he utilizado nada de código de Mono, ni siquiera lo he visto) y me parece útil para encontrar más fácilmente las tareas pendientes pero que no son lo suficientemente importantes o urgentes como para reportarlas como un bug, además de servir como complemento al bugzilla.
En la siguiente imagen podemos ver cómo se marcan las funciones con el atributo PigmeoToDo, que obviamente se compilan y se integran en los metadatos de los ejecutables y las librerías, es decir, los atributos son datos que se almacenan en pigmeo-compiler.exe, Pigmeo.Internal.dll, Pigmeo.dll, PIC16F716.dll… no son variables accesibles desde otras partes del programa.
un método marcado con el Custom Attribute PigmeoToDo
Entonces… ¿cómo sabemos qué métodos poseen el atributo PigmeoToDo?
He implementado una clase (Pigmeo.Internal.FindPigmeoToDos, dentro de la librería Pigmeo.Internal.dll) que puede utilizarse desde cualquier otro programa del proyecto Pigmeo para cargar las librerías y los ejecutables uno a uno y mostrar las funciones marcadas con PigmeoToDo.
De momento el compilador puede llamarse con el parámetro todo o ToDo y conseguimos que el compilador se lea a sí mismo en tiempo de ejecución y nos muestre las cosas que faltan por hacer:
Cómo funciona Pigmeo
(Este artículo es una traducción de How Pigmeo Works, parte de la documentación oficial para desarrolladores de Pigmeo. Al contrario que la documentación para usuarios, la doc. para desarrolladores sólo se publicará en inglés)
Para entender cómo funciona Pigmeo, antes debemos entender cómo funciona .NET.
Cómo funciona .NET
Cuando quieres escribir una aplicación en C#, Visual Basic .NET, C++/CLI o cualquier otro lenguaje de .NET, lo primero que haces es escribir el código fuente. Este código fuente se compila a CIL/IL/MSIL, el lenguaje intermedio de .NET (parecido a otros tipos de lenguaje ensamblador), y se almacena en archivos .exe que contienen bytecodes de CIL (al igual que ocurre en java). Estos bytecodes son representaciones binarias del juego de instrucciones definido por CIL. Cabe destacar que estos archivos .exe no son ejecutables de Windows aunque tengan la misma extensión.
Los bytecodes de CIL almacenados en los ejecutables de .NET (los archivos .exe) se compilan a código máquina por el CLR (cuando el usuario lo ejecuta), la máquina virtual de .NET, y entonces son ejecutados por el procesador. Hay que tener en cuenta que CIL no está orientado a ninguna arquitectura de hardware en particular, por lo que cualquier máquina virtual (CLR) en cualquier arquitectura y cualquier sistema operativo puede compilar y ejecutar los archivos ejecutables de .NET.
Algunas implementaciones de .NET son Mono, la implementación de .NET hecha por Microsoft, DotGNU, Rotor…
Por lo tanto funciona de la siguiente manera:
[C# / VB.NET / C++/CLI / Boo / Chrome / J# / Nemerle / Ruby.NET / IronScheme / IronPython / IKVM.NET / cualquier otro lenguaje que sea compilado a CIL] => compilador => .exe + librerías en el GAC => Máquina Virtual (CLR) => código máquina => procesador
Cómo funciona Pigmeo
Si queremos ejecutar nuestra aplicación en un microcontrolador o algún tipo de sistema embebido, podemos ejecutar un CLR en él y dejar que sea el CLR quien compile y ejecute nuestros bytecodes en CIL (el archivo .exe), como lo hace el .NET Micro Framework, pero requiere muchísimos recursos, así que Pigmeo genera el código máquina en un ordenador común.
Desarrollando aplicaciones en .NET para microcontroladores usando Pigmeo, se escribe el código fuente y se compila a bytecodes de CIL de manera normal. Después Pigmeo Compiler toma el archivo .exe, lo junta con las librerías necesarias y convierte solamente las partes útiles de estos archivos a lenguaje ensamblador para la arquitectura de destino.
Una vez que tenemos nuestra aplicación compilada a lenguaje ensamblador ya podemos utilizar un programa ensamblador para convertirlo a código máquina listo para ser enviado al microcontrolador a través de un programador (como PIC³PROG o PICkit).
Cuando la aplicación haya sido grabada en el microcontrolador ya puede ejecutarse normalmente.
Como resumen:
[C# / VB.NET / C++/CLI / Boo / Chrome / J# / Nemerle / Ruby.NET / IronScheme / IronPython / IKVM.NET / cualquier otro lenguaje que sea compilado a CIL] => compilador => .exe + librerías en el GAC => Pigmeo Compiler => lenguaje ensamblador para la arquitectura de destino => programa ensamblador => código máquina => cualquier programador/grabador de microcontroladores => procesador del microcontrolador
Editor de lenguaje ensamblador integrado
Posted by Urriellu in Pigmeo Compiler on March 20th, 2008
Para facilitar la depuración o para cualquiera que quiera ver el código fuente generado por Pigmeo Compiler he implementado un sencillo editor de texto con resaltado de sintaxis para lenguaje ensamblador, que abre automáticamente el archivo con el que estemos trabajando.
Vídeo de ejemplo del editor de lenguaje ensamblador [ogg + theora]
Vídeo de ejemplo del editor de lenguaje ensamblador [avi + xvid]
Video de ejemplo del compilador
Posted by Urriellu in Pigmeo Compiler on March 18th, 2008
La GUI de WinForms corriendo en Gentoo Linux, sobre Mono 1.2.6. Versión 0.0.9999-SVN de Pigmeo Compiler:
Vídeo de ejemplo de Pigmeo Compiler [ogg + theora]
Vídeo de ejemplo de Pigmeo Compiler [avi + xvid]
Se ve cómo se elige un archivo a ejecutar, automáticamente se configuran las rutas para los archivos de destino; luego configuramos para que se muestren los mensajes de depuración y cambiamos entre español e inglés un par de veces para que se vea cómo los controles se adaptan a cada idioma. Se vuelve al panel de compilación y compilamos.
Algunos mensajes de salida están en inglés y otros en español. Esto es así porque todo lo relacionado con los desarrolladores de pigmeo (incluyendo los mensajes de depuración) solamente está en inglés, ya que los usuarios finales no tienen por qué ver estos mensajes, en cambio los textos verbose (los precedidos por “INFO:”) se muestran en español (salvo que aún no estén traducidos).
Creo que para ser una versión de desarrollo (aún no hay ninguna release estable) no está nada mal.
Interfaz WinForms del compilador actualizada
Posted by Urriellu in Pigmeo Compiler on March 17th, 2008
Ya he añadido todas las opciones de configuración del compilador a la interfaz WinForms.
El resultado (corriendo en linux):
Como se ve, lo he traducido todo al español. El idioma puede elegirse desde esta misma ventana (está al final del panel, se ve en la segunda imagen) y los controles cambian de posición y se redimensionan automáticamente según el idioma, así que la propia interfaz gráfica se adapta y no se necesitan distintas versiones para cada idioma.
El compilador de Pigmeo ya tiene cara
Posted by Urriellu in Pigmeo Compiler on March 16th, 2008
La primera interfaz gráfica que voy a implementar es la de WinForms, que aunque ni es estándar ni libre, sí es la más fácil de portar ya que Mono la soporta casi perfectamente en linux.
Una imagen del compilador utilizando la interfaz de WinForms en Gentoo Linux:
La misma versión del compilador, usando exactamente la misma interfaz y utilizando el mismo binario, sin necesidad de recompilarlo siquiera, corriendo en Windows XP con estilo clásico:
Y de nuevo en Windows XP pero esta vez utilizando el estilo de Windows XP:
Además el compilador automáticamente ha detectado que mi sistema está configurado en español, así que la interfaz se muestra en español (el idioma puede configurarse en tiempo de ejecución desde el panel de configuración del compilador), como puede leerse en el menú “Archivo”, pero como todos los demás strings aún no están traducidos entonces se muestran en inglés.
Console.WriteLine(), salida estántar (stdout) y salida de error (stderr)
Posted by Urriellu in Pigmeo Compiler on March 15th, 2008
Los que programamos en C# estamos tan acostumbrados a usar Console.WriteLine() para todo que a veces se nos olvida que existen las entradas y salidas estándares.
Console.WriteLine() y Console.Out.WriteLine() escriben un string a la salida estándar seguido de un caracter de fin de línea. Console.In es un objeto TextReader que nos permite leer fácilmente la entrada estándar. Console.Error.WriteLine() es quien nos permite mostrar un string en una línea de la salida de error.
He cambiado el código necesario para que los mensajes de error que se muestren por consola se redirijan a la salida de error, y tanto los warnings como los mensajes de aviso y depuración se muestren en la salida estándar. Cuando estamos en una interfaz gráfica todos estos mensajes se muestran mezclados en un solo TextBox, y además se envían inevitablemente (por elección de diseño, no por culpa de la implementación) a las salidas estándar y de error. De paso he agrupado los métodos que gestionan el envío de mensajes entre la lógica de compilación y las interfaces gráficas, de manera que esté todo bien organizado y sólo haya un sitio desde el que realmente se llamen a las entradas y salida estándar.
Por otro lado, y siguiendo mi intención de hacer el compilador tan portable como sea posible, lo he implementado todo de manera que si en el futuro se añaden al compilador interfaz ncurses o para el framebuffer, los mensajes que vayan a la salida estándar y de error no se muestren en la consola.
Detectar automáticamente la consola, e ignorar la interfaz gráfica
Posted by Urriellu in Pigmeo Compiler on March 14th, 2008
Aunque he mantenido la lógica del compilador bien separada de las interfaces gráficas, lo que sí he hecho es integrar todas las interfaces dentro del mismo ejecutable. Al principio mi intención era generar una librería para cada interfaz gráfica y que ésta se cargase según los parámetros pasados desde la consola, o bien crear una librería que incluyese la lógica del compilador y además un ejecutable por cada interfaz existente, debiendo llamar a ejecutables distintos según la interfaz deseada. El problema es que para mostrar los avisos y errores generados por el compilador, y mostrar claramente el porcentaje de progreso de la compilación me vi obligado a integrar tanto la lógica de compilación como las interfaces en el mismo ejecutable, a no ser que quisiese emplear temporizadores para ir actualizando el progreso de compilación y mostrarlo de manera actualizada en la pantalla.
Entonces surgió otro problema: ¿qué ocurre cuando ejecutamos el compilador y en el sistema no hay soporte para cierta librería gráfica, o estamos en una consola, sin X11 ni Windows?
Por defecto la máquina virtual muestra una excepcion de inicialización de una clase perteneciente a la librería gráfica utilizada, pero es una solución muy poco elegante. Por lo tanto, Pigmeo Compiler detecta la plataforma de ejecución automáticamente (utilizando Environment.OSVersion.Platform) y se ejecuta por defecto utilizando la interfaz de GTK# cuando se encuentra en sistemas derivados de Unix y la interfaz WinForms cuando está en Windows, pero además se detecta cuándo una librería gráfica no está disponible, por lo que si ejecutándose desde Linux (por ejemplo) se intenta utilizar GTK# y no está disponible, automáticamente se cambiará a la interfaz basada en WinForms, que también funciona en Linux. Además, si ninguna interfaz gráfica está disponible (porque la máquina virtual no encuentre las librerías necesarias o porque nos encontremos en una interfaz sólo texto) se muestra un aviso y se comienza la compilación desde la consola.
Por supuesto, esto solamente es el comportamiento por defecto, y podemos elegir manualmente la interfaz que queremos utilizar con el parámetro –ui de Pigmeo Compiler.
monomerge
Posted by Urriellu in Pigmeo Compiler on March 13th, 2008
Al poco tiempo de haber comenzado a programar Pigmeo Compiler encontré monomerge, una aplicación que agrupa varios assemblies de .NET (ejecutables y librerías) en un solo ejecutable. Aparentemente me iba a ahorrar gran parte del trabajo, lo que viene a ser casi todo el frontend de Pigmeo Compiler.
Tras varios intentos fallidos y tras darme cuenta de que gran parte del código tendría que reescribirlo de todas formas, desistí y comencé a trabajar en mi propio “mezclador” de assemblies. Con esto me refiero a que monomerge agrupa las librerías y los ejecutables con todos los tipos que incluyen, es decir, todas las clases y estructuras que existen en los assemblies. Al principio parece una buena idea, es bastante cómodo de implementar y tenemos lo que queremos: un solo ejecutable con todas las librerías necesarias, sólo necesitamos una máquina virtual (el CLR de .NET) y ya tenemos nuestra aplicación funcionando sin un montón de librerías molestando. Realmente esto no es tan sencillo, porque los compiladores que generan estos assemblies incluyen en ellos absolutamente todos los tipos (clases y estructuras) que estén definidos en el código fuente, y eso es un problema a la hora de compilar para un microcontrolador, con recursos muy limitados, ya que la mayoría de propiedades y métodos implementados en las clases y estructuras nunca llegan a usarse.
Por lo tanto monomerge descartado, y estoy escribiendo el frontend del compilador desde cero, procesando instrucción a instrucción (en CIL) empezando por el EntryPoint de la aplicación (normalmente la función estática main(), pero no necesariamente), y detectando exactamente qué propiedades (variables) y métodos (funciones) y de qué tipos (clases y estructuras) realmente se utilizan en la aplicación, para lograr que en la aplicación compilada para microcontroladores sólo se implementen las cosas utilizadas y realmente necesarias, y no haya una sobrecarga innecesaria y completamente ineficiente.
