Reescribiendo el Frontend y el Backend
Posted by Urriellu in Pigmeo Compiler on October 29th, 2008
Tras mucho pelearme con la estructura interna del compilador durante meses, he decidido reescribir gran parte de Pigmeo Compiler.
Hasta ahora, el proceso de compilación seguía más o menos el siguiente esquema:
Se leía el programa del usuario (.exe que contiene CIL bytecodes) utilizando Mono.Cecil (una capa de abstracción sobre System.Reflection), se buscaban todas sus referencias, se creaba un nuevo ejecutable de .NET (.exe) desde cero, al que llamamos bundle, que contenía solamente las partes útiles del programa del usuario junto con las partes útiles de las librerías a las que se hacía referencia (es decir, las partes necesarias por el programa del usuario), después se añadía un CustomAttribute al bundle para indicar la arquitectura para la que estábamos compilando, el bundle era modificado directamente mediante reflexión para ser optimizado, y finalmente el Backend procesaba el código CIL contenido en el bundle buscando “conjuntos de instrucciones” que representasen operaciones conocidas (por ejemplo la instrucción ldc.i4 seguida de stsfld indicaría que se está almacenando un valor constante en una variable estática) para generar finalmente el código en lenguaje ensamblador.
Este proceso había sido diseñado de esta manera, centrándose en trabajar sobre ejecutables de .NET y siendo CIL el código intermedio utilizado internamente por el compilador, para ser simple y corto, sin necesidad de inventar nuevos lenguajes intermedios. No obstante, generar ejecutables de .NET desde cero y modificarlos es mucho más complicado de lo que parece, incluso utilizando librerías como Cecil que facilitan la tarea. Casi haría falta un MBA en .NET y C#, aunque con paciencia también se puede lograr.
Por lo tanto, durante los últimos meses he estado reescribiendo grandes partes de Pigmeo Compiler y, sobre todo, añadiendo capas de abstracción y pasos intermedios.
La aplicación del usuario sigue siendo leída utilizando Cecil, pero ahora existe una capa de abstracción sobre Cecil que se encuentra en el namespace Pigmeo.Internal.Reflection, y permite reflejar ejecutables de .NET (sólo lectura) de manera sencilla e incluye características no soportadas por System.Reflection ni por Mono.Cecil, además de más características especializadas que, aunque no tienen relación directa con .NET, son útiles de cara al proceso de compilación. Por ejemplo, podemos reflejar un archivo y una propiedad nos devuelve una referencia al objeto que representa la librería de dispositivo que ese programa está usando; también podemos saber fácilmente la arquitectura o microcontrolador para los que está diseñada la aplicación, o podemos desensamblar de manera sencilla todo el programa, o clases o métodos individuales (se utiliza especialmente para depurar el compilador).
Tras reflejar el programa del usuario (usando Pigmeo.Internal.Reflection), en lugar de generar el bundle con CIL bytecodes como se hacía antes, ahora se convierte el programa a PIR (Pigmeo Intermediate Representation) que, como su nombre indica, es una representación intermedia. Normalmente esto se hace con lenguajes intermedios, pero realmente no necesitamos un lenguaje, sólo una jerarquía de clases que representen el programa, así que no existe una sintaxis “oficial” para convertir PIR a string, aunque sí que están implementadas todas las funciones para poder mostrar por pantalla el programa una vez convertido a PIR (y, como en el caso de P.I.Reflection, se utiliza sobre todo para depurar el compilador).
PIR está diseñado para ser fácilmente manipulable (y fácil de comprender al mostrarlo en pantalla), de manera que podamos hacer múltiples cambios al programa y, sobre todo, diversas optimizaciones sin romper la lógica original del programa ni complicarnos con Cecil ni System.Reflection.
Una vez convertido el programa a PIR, éste es optimizado de la misma manera para todas las arquitecturas, tras lo cual se envía el PIR optimizado al Backend. El Backend estaba diseñado para “recibir” CIL bytecodes (del bundle) por lo que también ha sido reescrito para poder manejar PIR. En la primera fase del Backend se lee la arquitectura de destino del programa y se envía el PIR al Backend especializado en dicha arquitectura. Allí, el PIR vuelve a ser optimizado y modificado específicamente para la arquitectura de destino, y una vez preparado, ya puede convertirse el PIR a lenguaje ensamblador.
Resultados del II Concurso Universitario de Software Libre
El II Concurso Universitario de Software Libre, en el que el proyecto Pigmeo participaba, ha terminado con estos resultados.
De entre los 95 proyectos y 6 finalistas, Pigmeo ha quedado finalista de la categoría “Mejor Proyecto Innovador”, aunque no ha conseguido el primer premio, que se lo llevó el robot R4P. Quiero dar la enhorabuena también a Dato por su proyecto Minirok, a Antonio por XMLEye, a Juan Pedro por Psychosynth y a Juan Belón por zenphp.
Aunque el concurso haya terminado, el desarrollo del proyecto continuará en el sitio web oficial de Pigmeo. Os recomiendo que os apuntéis a la lista de correo de anuncios sobre el proyecto para mantenerse al día.
Pigmeo 0.0.2 ya disponible
Resulta que Pigmeo 0.0.1 tenía varios fallos bastante graves y no me había dado cuenta, así que me veo obligado a publicar esta nueva versión que solo arregla esos fallos y no añade mucho más (aunque sí tiene varias cosas nuevas).
Bugs resueltos:
- La compilación no funcionaba correctamente (se requería Mono.Cecil.dll antes de iniciar la compilación, pero el script copiaba el archivo tras la compilación, por lo que daba un error de compilación)
- Pigmeo Compiler no se podía ejecutar en Windows
- La gestión de excepciones descontroladas (unhandled exceptions) no funcionaba correctamente en Windows cuando se utilizaba la interfaz de WinForms. Ahora funciona perfectamente en Windows y en Linux, además lo hace de manera más limpia
Nuevas características:
- Usando Pigmeo Compiler podemos mostrar información sobre un ejecutable de .NET (archivos .exe) antes de compilarlo, tanto desde la consola como desde la interfaz de WinForms
- Cuando salta una excepción desconocida mientras estamos ejecutando la interfaz WinForms, se genera un resumen muy detallado del error y el estado de la aplicación antes de que saltase la excepción, y se permite enviar por e-mail a los desarrolladores
- Se cambió completamente la forma de almacenar los textos de los distintos idiomas. Ahora todo puede traducirse a cualquier idioma mucho más fácilmente
- Añadido un programa de ejemplo escrito en C# y en Visual Basic .NET. El código fuente está acompañado por el .exe y el código en lenguaje ensamblador generado por Pigmeo Compiler
Página de la nueva versión: Pigmeo 0.0.2
Obteniendo información del ejecutable
Posted by Urriellu in Pigmeo Compiler on April 13th, 2008
Antes de compilar un archivo .exe para convertirlo a lenguaje ensamblador, podemos obtener información sobre el archivo, tanto desde la consola como desde la interfaz WinForms (pulsando en el botón que tiene un icono de información).
Cuando se soporten más interfaces gráficas será muy simple hacer que desde ellas también se pueda mostrar esta información.
Pigmeo 0.0.1 ya disponible
Es una versión alpha, no contiene suficientes características para ser usada para crear casi ningún programa útil.
Sólo necesitas tener instalada una máquina virtual de .NET (CLR), como Mono o Microsoft .NET, y debería funcionar en cualquier sistema operativo para el cual haya disponible un CLR de .NET. Por el momento se ha comprobado que funciona en Linux y en Windows.
Soporta las siguientes características:
- Arquitectura PIC14
- Modelo PIC16F716
- Acceder a variables estáticas definidas tanto en el propio programa como en librerías externas a las que se hace referencia
- Se soportan más de la mitad de los registros disponibles en el PIC16F716
- Forzar al compilador a que llame a ciertas variables de determinada manera, usando el Custom Attribute [AsmName()]
- Forzar al compilador a que almacene ciertas variables en posiciones determinadas de memoria, usando el Custom Attribute [Location()]
- Asignar valores constantes a variables estáticas de tipo uint8/byte
- Copiar variables estáticas de tipo uint8/byte
- Sumar dos variables de tipo uint8/byte
- Sumar dos variables de tipo uint8/byte con comprobación de desbordamiento
- Restar dos variables de tipo uint8/byte
- Bucles infinitos
- Instrucción goto
- Posibilidad de elegir qué hacer cuando el programa termina:
- Quedarse en un bucle infinito sin hacer nada
- Reiniciar el programa
- Posibilidad de elegir cómo implementar el soporte para excepciones:
- No se permiten excepciones
- Terminar el programa cuando salte cualquier excepción
- Interfaz para la línea de comandos
- Interfaz gráfica WinForms
Toda la información sobre esta versión está disponible en http://en.pigmeo.org/wiki/Pigmeo_0.0.1
Compilando desde WinForms y desde la consola
Posted by Urriellu in Pigmeo Compiler on April 6th, 2008
Compilando desde Linux usando la interfaz de WinForms:
Compilando desde la consola en Linux:
Este último vídeo también incluye algunos ejemplos de los parámetros que se le pueden pasar al compilador, y se ve cómo automáticamente detecta el idioma del sistema (que en la consola se configura mediante variables de entorno).
Compilando código escrito en Visual Basic .NET
Programa de ejemplo escrito en Visual Basic .NET
Código fuente en lenguaje ensamblador generado por Pigmeo Compiler
Y un pantallazo de Pigmeo Compiler compilando este programa desde linux, utilizando la interfaz de WinForms:
Pigmeo Compiler compilando
Posted by Urriellu in Pigmeo Compiler on April 3rd, 2008
Compilando el siguiente programa escrito en C#: ejemplo001.cs
El compilador de C# que más nos guste nos genera el .exe (que hace referencia a PIC16F716.dll) y Pigmeo Compiler lo convierte a lenguaje ensamblador: ejemplo001.asm. Podemos fijarnos en que se compiló para el PIC16F716 (sin especificarlo a la hora de utilizar Pigmeo Compiler), ya que el compilador de pigmeo automáticamente detecta la “librería de dispositivo” que se utilizó cuando el programa en C# fue compilador a .exe y sin intervención del usuario sabe para qué arquitectura y qué rama/dispositivo estamos compilando, en este caso la arquitectura es PIC14 y el dispositivo es PIC16F716.
Y con mpasm, gpasm o cualquier otro programa ensamblador (que sea compatible) para PICs de 8 bits generamos el archivo binario (.hex) que podemos grabar en nuestro microcontrolador.
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.
C# 3.0
Para estructurar el código de manera más organizada y sobre todo para poder utilizar extension methods estoy escribiendo el código en C# 3.0. Puede parece algo extraño porque no es demasiado utilizado aún, pero hay partes del framework que no serían nada útiles sin los extension methods. No es mayor problema ya que desde hace bastante tiempo el compilador de mono (mcs/gmcs/smcs) soporta gran parte de C# 3.0 y la última versión ya lo soporta casi todo. La versión de la máquina virtual implementada por Microsoft que los soporta ya hace tiempo que está disponible como descarga para windows y Visual Studio 2008 (en la calle desde el 19 de noviembre de 2007) también permite elegir la versión del lenguaje para la que compilar (incluyendo la 3.0).
No obstante los usuarios finales ni siquiera necesitan instalar una de las últimas versiones de la máquina virtual de .NET (CLR) porque los binarios generados son compatibles con la versión 2.0 ya que las características añadidas a C# 3.0 son sólamente syntactic sugar, aunque quienes quieran utilizar estas funciones añadidas al .NET Framework en sus programas necesitarán una versión actual que lo soporte.
Como ya he comentado, ya principal razón de compilar para C# 3.0 es poder utilizar extension methods, que nos permitirán añadir funciones muy útiles a las clases ya existentes del .NET Framework sin necesidad de reescribir las clases ni sustituir las librerías, por ejemplo podremos hacer “byte a=5; a.Getbit(3);” para obtener el tercer bit de la representación binaria del valor de la variable “a”. Me hubiese gustado poder hacer lo mismo utilizando indizadores, por ejemplo: “byte a=5; a[3];” lo que nos permitiría leer y modificar bits independientes de manera mucho más cómoda. C# 3.0 no soporta extensiones de indizadores ni propiedades pero se espera que C# 4.0 sí lo haga.
Pautas de desarrollo
Antes de que se una cualquier otro desarrollador quiero terminar la estructura principal del proyecto, sobre todo del compilador y el framework, porque son decisiones de diseño y no de implementación, y ese tipo de decisiones prefiero hacerlas sólo ya que de otra manera es mucho más fácil que acabemos discutiendo. Para el final del concurso espero tener terminado el diseño global de compilador y framework, y de momento acabo de terminar las pautas de desarrollo (en inglés) que indican a grandes rasgos cómo se debe escribir el código, más que nada para que sea lo más legible, usable y portable posible, aunque no es demasiado pedante y da bastante libertad al desarrollador.
Supongo que la regla más “incómoda” sea la de documentar casi todo el código fuente con comentarios XML, y documentar absolutamente todas las clases, métodos y variables públicas del framework. Esto es así porque aunque la documentación “real” cueste escribirla, los comentarios en XML son muy útiles para entender el código, y sobre todo el código del framework que va a ser utilizado por los usuarios finales para escribir sus propios programas para microcontroladores. No puedo permitir que un usuario normal quiera utilizar alguna clase incluída en pigmeo-framework y no tenga ni la más mínima idea de cómo utilizarlo. Obligando a los desarrolladores de pigmeo a escribir comentarios XML me aseguro de que cuando un usuario escriba código fuente y su entorno de desarrollo le autocomplete el nombre y los parmámetros de las funciones y variables estos usuarios vean claramente una pequeña descripción de lo que van a utilizar. No hay nada más incómodo que utilizar librerías sin documentar.
AOP, reflexión (reflection), Cecil
Posted by Urriellu in Pigmeo Compiler on November 26th, 2007
El proyecto pigmeo se divide en varios subproyectos. La piedra angular del compilador (pigmeo-compiler uno de los subproyectos) es su paradigma: la programación orientada a aspectos. Utilizando las clases del namespace System.Reflection de .NET podemos modificar directamente los binarios de .NET. Como System.Reflection es algo engorroso utilizaré un librería intermedia: Cecil. Es GPL así que no hay ningún problema en utilizarla. El usuario final obviamente no tendrá que preocuparse por Cecil, reflexión ni AOP ya que sólo se utiliza desde pigmeo-compiler, y no desde pigmeo-framework (el framework utilizado por los usuarios finales).
Cecil está muy bien organizado y permite acceder a todas las clases, métodos, instrucciones en lenguaje intermedio (CIL)… mediante una jerarquía bien estructurada. El gran problema de Cecil es que no tiene absolutamente nada de documentación, solo unos pocos ejemplos, y ni siquiera está documentado el código fuente mediante XML (muy útil para ver la descripción de clases y objectos en el autocompletado del entorno de desarrollo), por lo que te encuentras con cientos o incluso miles de clases y funciones con nombres extraños y sin ningún tipo de explicación, así que acceder a algunas partes del ejecutable que se está intentando modificar resulta prácticamente imposible.
Cecil se utilizará para la primera parte del compilador: el frontend. El frontend lee el ejecutable de .NET y genera OTRO ejecutable con el mismo programa pero organizado de una manera totalmente diferente, parecida al bajo nivel (o más bien “desorganización”) del lenguaje ensamblador. Por ejemplo las clases estáticas con sus propiedades también estáticas funcionan como variables globales en C y C++, son accesibles desde cualquier parte del programa. Estas propiedades estáticas en el frontend se cambian de nombre a uno válido para el programa ensamblador, y se agrupan en una sola clase que más tarde en el backend específico para la arquitectura de destino se convertirán de golpe a variables globales en lenguaje ensamblador. La idea es que a partir del ejecutable de .NET generado por el compilador de C#, VB.NET o el lenguaje que sea, se genere un segundo ejecutable de .NET tan válido como el primero pero estructurado de manera que sea mucho más fácil convertirlo a lenguaje ensamblador, eliminando la complicada estructura original del ejecutable y además optimizando el código para todas las arquitecturas, es decir, optimizaciones que son válidas para cualquier arquitectura de destino, y no dependen de ninguna en particular. Las optimizaciones específicas para cada arquitectura se procesarán en el backend.
Por si a alguien le parece extraño que diga “ejecutable de .NET” que sepa que el compilador del lenguaje de alto nivel utilizado (C#, VB.NET,C++/CLI, nemerle…) lo que genera no es código máquina, sino un “.exe” que aunque comparte la extensión de los ejecutables nativos de Windows NO lo es, sino que es un archivo que contiene, entre otras cosas, el código en lenguaje intermedio (CIL) que para ser ejecutado debe ser interpretado por una máquina virtual o CLR (Microsoft .NET, mono, Portable .NET…).
No me extiendo más, porque para eso está la documentación para desarrolladores.
