|
Traductor Euphoria a C
1. Introducción El Traductor Euphoria a C traducirá cualquier programa Euphoria a su equivalente de código C. Existen versiones del traductor para Windows, DOS, Linux y FreeBSD. Después de traducir un programa Euphoria a C, puede compilarlo y enlazarlo usando uno de los compiladores de C soportados. Esto dará como resultado, un ejecutable que normalmente correrá mucho más rápido que si se utiliza el intérprete Euphoria. Se asume que ya tiene instalado el paquete Intérprete Euphoria 2.4 en su sistema, y que las variables de entorno EUDIR y PATH están correctamente establecidas. Para cada compilador de C, en Windows, DOS, Linux o FreeBSD, encontrará un archivo .ZIP en el sitio de RDS, conteniendo:
1. el traductor (uno por plataforma)
ec.exe - DOS
ecw.exe - Windows
ecu - Linux
ecu - FreeBSD
2. una librería de tiempo de ejecución (una por compilador de C)
ec.lib - DOS (Watcom)
ec.a - DOS (DJGPP)
ecw.lib - Windows (Watcom)
ecwl.lib - Windows (Lcc)
ecwb.lib - Windows (Borland)
ecu.a - Linux (GNU)
ecu.a - FreeBSD (GNU)
3. (Watcom solamente) archivos para soportar el expansor DOS CauseWay
cwc.exe - compresor de archivos
le23p.exe - conversor de formato
cwstub.exe - el expansor DOS
4. (DJGPP solamente) la librería gráfica Allegro, compilada especialmente para
el traductor. Descargar liballeg.zip
Para instalar el Traductor
Euphoria a C, poner los archivos .exe y los de librería
requeridos en el directorio euphoria\bin.
El directorio euphoria\include ya
contiene el archivo euphoria.h, un
archivo de inclusión de C necesario para traducir todos los programas.
Nota:
El Traductor trabaja normalmente con GNU C en Linux o FreeBSD, tanto como con Watcom C o DJGPP C en DOS, y con Watcom C, Lcc o Borland 5.5 en Windows. Las implementaciones de Watcom y GNU C son 100% compatibles con el Intérprete Euphoria. Los otros son 99% compatibles. Recomendamos Borland sobre Lcc. Borland compila más rápido, produce mejor código y tiene muy pocos errores en comparación a Lcc. Se probó el Traductor con GNU C y la librería ncurses disponible en Red Hat Linux 5.2 o posterior, y con FreeBSD 4.5 o posterior. También se lo probó con Watcom C/C++ 9.5, 10.6 y 11.0. El compilador Watcom 11.0 es gratuito y de código abierto. Búsquelo en: http://www.openwatcom.org El paquete Watcom DOS32 incluye el expansor DOS y compresor de archivos CauseWay DOS. CauseWay es ahora gratuito y de código abierto. Puede encontrarlo más acerca suyo en: http://www.devoresoftware.com emake.bat y objfiles.lnk enlazarán automáticamente con el expansor CauseWay. Otros expansores DOS, tales como DOS4GW, no trabajan bien con el Traductor. El Traductor busca "WATCOM", "LCC", "BORLAND" o "DJGPP" tanto como variables del entorno como directorios en PATH. Así, generará un archivo emake.bat que invocará al compilador y enlazador adecuados. Notas:
Ejecutar el Traductor es similar a ejecutar el Intérprete. En DOS debería escribir: ec shell.ex
o
ec shell
pero en lugar de correr el programa .ex, el Traductor
creará varios archivos fuente de C. También creará
un archivo llamado emake.bat que compilará
y enlazará los archivos de C por Ud. Escriba solamente:
emake
Cuando la compilación y el enlazado de C terminen, obtendrá
un archivo llamado: shell.exe
Al ejecutar shell.exe, debería correr igual que si hubiera escrito: ex shell para ejecutarlo con el Intérprete, excepto que debería ejecutarse mucho más rápido. Nota para usuarios de Linux y FreeBSD:
Opciones de la línea de comandos Si ocurre que tiene más de un compilador de C para una plataforma dada, puede elegir el que desee usar, mediante una opción de la línea de comandos:
en la línea de comandos para ec o ecw, por ejemplo:
ecw -bor pretend.exw
Para hacer un archivo .dll de Windows,
o un .so de Linux o FreeBSD,
agregue solamente -dll a la línea de comandos, por ejemplo:
ecw -bor -dll mylib.ew
Nota:
Agregando simplemente -dll a la línea de comandos, el Traductor generará un archivo .dll de Windows .dll (.so en Linux/FreeBSD), en lugar de generar un programa ejecutable. Puede traducir y compilar un conjunto de rutinas Euphoria útiles, y compartirlas con otras personas, sin necesidad de entregar sus archivos fuente. Además, sus rutinas correrán mucho más rápido al estar traducidas y compiladas. Tanto los programas traducidos/compilados, como los interpretados podrán ser capaces de usar su librería. Solamente las funciones y procedimientos globales de Euphoria, es decir, aquellos declarados con la palabra clave "global", se exportarán desde el archivo .dll (.so). Cualquier programa Euphoria, sea traducido/compilado o interpretado, puede vincularse con un .dll (.so) de Euphoria usando el mismo mecanismo que le permite vincularse a un .dll (.so) escrito en C. El programa llama primero a open_dll() para abrir el archivo .dll o .so, entonces llama a define_c_func() o define_c_proc() para cualquier rutina que quiera invocar. Llama a esas rutinas usando c_func() y c_proc(). Ver library.doc por más detalle. Los nombres de las rutinas exportadas desde .dll de Euphoria .dll variarán según el compilador de C que utilice. GNU C en Linux o FreeBSD exporta los nombres exactamente como aparecen en el código C producido por el Traductor, por ejemplo, una rutina Euphoria:
global procedure foo(integer x, integer y)
se exportaría como "_0foo" o tal vez como "_1foo", etc. El guión
de subrayado y el dígito se agregan para evitar un posible conflicto
de nombres. El dígito se refiere al archivo Euphoria en donde está
definido el símbolo. El archivo principal se numera como 0. Los archivos
include se numeran en el orden en que el compilador los encuentra. Debería
verificar el archivo fuente de C para estar seguro.
Lcc exportaría a foo() como "__0foo@8", donde 8 es el número de parámetros (2) cuatro veces. Puede verificar el archivo .def creado por el Traductor para ver todos los nombres exportados. El Traductor para Borland, también crea el archivo .def, pero en este archivo se renombran los símbolos exportados con el mismo nombre que se usó en el código fuente de Euphoria, por lo tanto, foo() se exportaría como "foo". En el caso del compilar Watcom, ocurre lo mismo que con el de Borland, pero en lugar de crear un archivo .def, se agrega un comando EXPORT a objfiles.lnk por cada símbolo exportado. Con Borland y Watcom, se puede editar los archivos .def o objfiles.lnk, y volver a ejecutar emake.bat, para renombrar los símbolos exportados, o remover aquellos que no desea exportar. Con Lcc, se pueden quitar símbolos, pero no renombrarlos. No es imperioso tener esmerados nombres exportados, puesto que el nombre solamente necesita aparecer una vez en cada programa Euphoria que use el archivo .dll, es decir, en un solo comando define_c_func() o define_c_proc(). El autor de un archivo .dll posiblemente les entregue a sus usuarios un archivo de inclusión de Euphoria conteniendo los comandos define_c_func() y define_c_proc() necesarios, e incluso proveer un conjunto de rutinas Euphoria que "envuelvan" a las llamadas a las rutinas en el archivo .dll. Al llamar a open_dll(), cualquier instrucción Euphoria de alto nivel en el .dll o .so se ejecutará automáticamente, como en un programa normal. Esto le da a la librería la oportunidad de inicializar sus estructuras de datos antes de la primera llamada a una rutina. Para algunas librerías, no se necesita la inicialización. Para pasar datos Euphoria (átomos y secuencias) como argumentos, o recibir un objeto Euphoria como un resultado, se necesitará agregar los siguientes nuevos tipos de datos a euphoria\include\dll.e: -- Nuevos tipos Euphoria para argumentos y valores de retorno en .dll (.so):
global constant
E_INTEGER = #06000004,
E_ATOM = #07000004,
E_SEQUENCE= #08000004,
E_OBJECT = #09000004
Uselos en define_c_proc()
y define_c_func() del mismo modo que
usa C_INT, C_UINT etc. para llamar los .dll y los .so de C.
Actualmente, los números de archivo devueltos por open(), y el ID de rutina devuelto por routine_id(), pueden ser pasados y devueltos, pero la librería y el programa principal tienen por separado, su propia idea de lo que esos números significan. En lugar de pasar el número de archivo a un archivo abierto, podría pasar el nombre del archivo y permitir abrir el .dll (.so). Desafortunadamente no hay una solución simple para el pasaje del ID de rutina. Esto será cambiado en el futuro. Las .dll (.so) se pueden usar también con programas C, mientras que solo se intercambien valores enteros de 31 bits. Si se tiene que pasar un puntero de 32 bits o un valor entero, y se tiene el fuente del programa en C, se podría pasar el valor en dos argumentos enteros de 16 bits (16 bits superiores y 16 bits inferiores) y combinarlos en una rutina Euphoria para obtener el átomo deseado de 32 bits.
En DOS32 con Watcom, si el Traductor encuentra los archivos de CauseWay, cwc.exe y le23p.exe en euphoria\bin, agregará comandos a emake.bat para comprimir su archivo ejecutable. Si no desea la compresión, puede editar emake.bat, o quitar o renombrar cwc.exe y/o le23p.exe. En Linux, FreeBSD, Windows, y DOS32 con DJGPP, emake no incluye un comando para comprimir el archivo ejecutable. Si desea comprimir el ejecutable, le sugerimos que lo intente con el compresor gratuito UPX. Puede obtener UPX en: http://upx.sourceforge.net El Traductor borra las rutinas que no se usan, incluyendo aquellas que están en los archivos de inclusión estándar de Euphoria. Después de borrar las rutinas sin uso, busca iterativamente otras rutinas que estén sin uso hasta hallarlas todas. Esto puede hacer una gran diferencia, especialmente con programas basados en Win32Lib, donde se incluye un gran archivo, pero muchas de las rutinas allí incluidas no se usan. No obstante, su archivo ejecutable compilado será probablemente tan grande como cualquier programa Euphoria enlazado con el Intérprete. Esto se debe en cierto modo a que el Intérprete es un ejecutable comprimido. También, los comandos Euphoria son extremadamente compactos cuando se almacenan en un archivo enlazado. Necesitan más espacio después de ser traducidos a C y compilados dentro del código de máquina. Las futuras versiones del Traductor producirán ejecutables más pequeños y veloces. Todos los programas Euphoria se pueden traducir a C, y con unas pocas excepciones indicadas más abajo, correrán igual que con el Intérprete (pero más rápido). El Intérprete y el Traductor comparten el mismo analizador de código, por lo que deberían obtener los mismos errores de sintaxis, errores de variables no declaradas, etc, tanto uno como el otro. El Traductor lee enteramente el programa antes de intentar cualquier traducción. Ocasionalmente puede capturar un error de sintaxis que el Intérprete no vea, porque el Intérprete comienza ejecutando inmediatamente instrucciones de alto nivel, sin esperar el fin del programa. Esto también significa que si hay instrucciones de alto nivel en el programa que modifican un archivo que se incluye después, se obtendrá un resultado diferente con el Traductor. Muy pocos programas usan esta técnica de "inclusión dinámica". El Intérprete expande automáticamente la pila de llamadas (hasta que la memoria se agota), por lo que puede haber una cantidad enorme de llamadas anidadas. La mayoría de los compiladores de C, en la mayoría de los sistemas, tienen un límite preestablecido del tamaño de la pila. Consulte el manual de su compilador o enlazador si quiere incrementar el valor límite, por ejemplo si tiene una rutina recursiva que necesite miles de niveles de recursión. Modifique el comando de enlace en emake.bat. Para Watcom C, use OPTION STACK=nnnn, donde nnnn es la cantidad de bytes de espacio de pila. Nota:
Debería depurar su programa con el Intérprete. Cuando el código de C se cancela, típicamente se obtiene una excepción de máquina muy críptica. Si se aborta el programa .exe traducido, la primera cosa que debería hacer es ejecutarlo en el Intérprete, usando las mismas entradas, y preferiblemente con la opción type_check activada. Algunas de la rutinas son capaces de capturar e informar errores en tiempo de ejecución, poniéndolos en el archivo ex.err. En cuanto a RDS concierne, cualquier programa ejecutable que se cree con este Traductor se puede distribuir sin cobrar regalías. Puede incorporar a su aplicación cualquier archivo Euphoria provisto por RDS. No se puede distribuir ninguna Edición Completa del Traductor, o ninguna librería en tiempo de ejecución que venga en la Edición Completa de ninguna plataforma. No se puede distribuir ninguna versión "hackeada" o "crackeada" (ingeniería inversa) de ninguna librería o el Traductor, sin diferenciar que sea de la Edición de Dominio Público o de la Edición Completa. En enero de 2000, Michael Devore donó al Dominio Público el expansor de DOS CauseWay, entregando su copyright, y alentando a todos a usarlo libremente, incluyendo el uso comercial. En general, si desea usar código Euphoria escrito por terceros, tendría que hacer honor a cualquier restricción que se aplique. En caso de duda, debería consultar. En Linux, FreeBSD y DJGPP para DOS32, la licencia de Librerías GNU normalmente no afectará a los programas creados con este Traductor. Simplemente por compilar con GNU C no le da a la Fundación de Software Libre (FSF) ninguna jurisdicción sobre su programa. Si enlaza estáticamente librerías de ellos, quedará sujeto a su licencia de Librerías, pero el procedimiento estándar de compilación/enlazado en emake no enlaza estáticamente ninguna librería de FSF, por lo que no debería tener ningún problema. La librería ncurses es la única enlazada estáticamente, y aunque FSF ahora mantiene el copyright, la licencia de Librerías GNU no se aplica a ncurses, debido a que fue donada a FSF por autores que no quieren que la licencia GNU se le aplique. Ver el aviso de copyright en ncurses.h. Renuncia:
Los programas (incluyendo .dll's y .so's) creados usando el Traductor libre de Dominio Público mostrarán un breve mensaje en la pantalla previa a la ejecución. Al registrar la Edición Completa del Traductor, obtiene:
Muchos programas grandes se tradujeron y compilaron exitosamente usando cada uno de los compiladores de C soportados y el Traductor es ahora completamente estable. Nota:
En algunos casos, se quiere traducir a C una enorme rutina de Euphoria, pero resulta ser demasiado grande para que el compilador de C la procese. Si tiene este problema, haga su rutina Euphoria más pequeña y más simple. También pruebe desactivando la optimización de C en emake.bat solamente para el archivo .c que falle. También puede ayudar, dividir una declaración única de varias variables, en declaraciones separadas de una variable por vez. Euphoria no tiene limitación en el tamaño de las rutinas, o para el tamaño de un archivo, pero la mayoría de los compiladores de C la tienen. El Traductor automáticamente producirá múltiples archivos .c a partir de un archivo de Euphoria grande para evitar saturar el compilador de C. Si prefiere evitar esto, divida una rutina grande en varias más pequeñas. Envíe los informes de errores a rds@RapidEuphoria.com
|