Al generar código, ¿qué lenguaje debe generar?

Question

He trabajado en una serie de productos que hacen uso de la generación de código. Parece ser la única forma de lograr tanto un alto grado de personalización del usuario como una alta velocidad de ejecución.

El inconveniente es que estamos exigiendo a los usuarios que instalen un compilador (principalmente en MS Windows).

Esto ha sido un dolor de cabeza constante, porque los proveedores como MS mantienen compiladores obsoletos, y algunos usuarios tienden a tener más de un compilador instalado.

Estamos considerando utilizar GNU C, y posiblemente C++, pero incluso allí, hay problemas de versiones continuas.

He considerado la posibilidad de generar lenguaje ensamblador, en un esfuerzo por salir de la compilación-versión-cinta, pero los lenguajes de ensamblaje son todos específicos de la máquina.

Idealmente, habría alguna manera de generar código generado que fuera flexible, rápido y no nos expondría a los caprichos de proveedores externos.

Tal vez estoy pasando por alto algo simple, como Java. Cualquier idea sería apreciada. Gracias.

Answer 1

Si está considerando C e incluso ensamblador, echar un vistazo a LLVM primera: http://llvm.org

Answer 2

empezar aquí: http://www.codegeneration.net/

Answer 3

puede ser que falte un poco de contexto aquí, pero ¿podrías fijar a sí mismo a una versión específica? Por ejemplo, .NET 2.0 se puede instalar junto con .NET 1.1 y .NET 3.5, así como otras versiones que saldrán en el futuro. Entonces, siempre que su código haga uso de una versión específica de un compilador, ¿cuál es el problema?

Answer 4

Una opción sería utilizar un idioma/entorno que proporcione acceso al compilador en el código; Por ejemplo, here is a C# example.

Answer 5

He considerado la posible generación de lenguaje ensamblador, en un esfuerzo por salir de la compilación-versión-cinta, pero los lenguajes de ensamblaje son todos específicos de la máquina.

que se llamaría un compilador :)

¿Por qué no te quedas a C90?

No he escuchado muchas violaciones graves de las normas del lado gcc, si no utiliza extensiones.

Y siempre puede distribuir una cierta versión de gcc junto con su producto, por ejemplo, 4.3.2, dando a los usuarios la opción de utilizar su propio compilador bajo su propia responsabilidad.

Siempre que genere todos los códigos (es decir, no incruste sus instrucciones en el código de los demás), no debería haber ningún problema al probar esta versión y utilizarla para compilar sus bibliotecas.

Answer 6

Por qué no enviar un compilador GNU C con su generador de código? De esta forma no tendrá problemas de versión, y el cliente puede generar código constantemente que se pueda usar.

Answer 7

Me limitaría al lenguaje que utiliza para generar ese idioma.Puede generar y compilar código Java en Java, código Python en Python, C# en C# incluso LISP en LISP, etc.

Pero no está claro si tales idiomas son lo suficientemente rápidos para usted. Para la velocidad máxima elegiría generar C++ y usar gcc para la compilación.

Answer 8

Parece que está buscando LLVM.

Answer 9

¿Por qué no utilizar algo como SpiderMonkey o Rhino? (Soporte Javascript en Java o C++). Puede exportar sus objetos a espacios de nombres de JavaScript y sus usuarios no tienen que compilar nada.

Answer 10

Si desea generar código asm, puede echar un vistazo a asmjit.

Answer 11

esto podría ser demasiado tarde. pero aquí están mis dos centavos. inserta un intérprete para un idioma como lua/scheme en tu programa. y generar código en ese idioma.

Answer 12

En el espíritu de "puede que no sea demasiado tarde para agregar mis 2 centavos" como en el caso de la respuesta de @ Alvin, aquí hay algo en lo que pensaría: si su aplicación está pensada para durar algunos años, es va a enfrentar varios cambios en cómo funcionan las aplicaciones y los sistemas.

Por ejemplo, supongamos que estaba pensando en esto hace 10 años. Estaba mirando a Dexter en ese momento, pero supongo que en realidad tienes recuerdos de cómo eran las cosas en ese momento. Por lo que puedo decir, el multihilo no era un gran problema para los desarrolladores de 2000, y ahora lo es. Entonces la ley de Moore se rompió para ellos. Antes, a la gente ni siquiera le importaba lo que sucedería en "Y2K".

Hablando de la ley de Moore, los procesadores se están volviendo bastante rápidos, por lo que tal vez ciertas optimizaciones ni siquiera serán necesarias. Y posiblemente la matriz de optimizaciones sea mucho más grande, some processors están recibiendo optimizaciones para varias cosas centradas en el servidor (XML, criptografía, compresión y regex! Estoy sorprendido de que se puedan hacer cosas en un chip) y también gasten menos energía (que es probablemente muy importante para el hardware de guerra ...).

Mi punto es que centrarse en lo que existe hoy como una plataforma para el futuro no es una buena idea. Haga que funcione hoy, y seguramente funcionará mañana (la compatibilidad con versiones anteriores es especialmente valorada por Microsoft, Apple no está mal y parece que Linux es muy liberal para que funcione como usted quiera).

Hay, sí, una cosa que usted puede hacer. Adjunte su tecnología a algo que simplemente no morirá (probablemente), como Javascript. Hablo en serio, las máquinas virtuales Javascript ahora se vuelven terriblemente eficientes y van a mejorar, además a todos les encanta, así que no va a desaparecer repentinamente. Si necesita más características/eficiencia, ¿puede apuntar a la CRL o JVM?

También creo que el multihebra será cada vez más un problema. Tengo la corazonada de que la cantidad de núcleos de procesador tendrá la propia ley de Moore. Y las arquitecturas son más que probables de cambiar, desde el aspecto del zumbido de la nube.

PD: En cualquier caso, creo que las optimizaciones C del pasado siguen siendo bastante válidas en los compiladores modernos.