lisp scheme llvm

¿Por qué no hay un buen esquema/lisp en llvm?



scheme (9)

Hay Gambit Scheme, MIT Scheme, PLT Scheme, Chicken Scheme, Bigloo, Larceny, ...; luego están todos los ceceos.

Sin embargo, no hay (que yo sepa) un solo esquema / lisp popular en LLVM, aunque LLVM proporciona muchas cosas agradables como:

  • más fácil de generar código que x86
  • fácil de hacer llamadas C FFI ...

Entonces, ¿por qué no hay un buen esquema / ceceo en LLVM?

no hay (que yo sepa) un solo esquema popular / ceceo en LLVM

Actualmente, llvm-gcc es lo más parecido a una implementación popular de cualquier lenguaje en LLVM. En particular, todavía no hay implementaciones maduras de lenguaje basado en LLVM con recolección de basura. Estoy seguro de que LLVM se utilizará como base para muchas implementaciones de idiomas de la próxima generación, pero eso requerirá mucho tiempo y esfuerzo, y es pronto para LLVM en este contexto.

Mi propio proyecto HLVM es una de las únicas implementaciones basadas en LLVM con recolección de basura y su GC es multinúcleo pero vagamente limitado: utilicé una pila de sombras para un "entorno no cooperativo" en lugar de piratear el código C ++ en LLVM para integrar la pila real para caminar.

GHC está experimentando con un backend de esquema y obteniendo resultados preliminares realmente emocionantes sobre su compilador de código nativo. De acuerdo, eso es Haskell. Pero recientemente impulsaron nuevos cambios en LLVM haciendo que las llamadas de cola sean más fáciles IIRC. Esto podría ser bueno para la implementación de algún esquema.

Hay un compilador Scheme muy pequeño y aparentemente no optimizado aquí:

http://www.ida.liu.se/~tobnu/scheme2llvm/

Tomando tu pregunta literalmente,

  • Escribir compiladores es difícil.
  • Una implementación deficiente como la vinculada anteriormente puede bloquear nuevas implementaciones. Las personas que van a la página de LLVM ven que ya hay un Esquema y no se molestan en escribirlo.
  • Hay un número limitado de personas que escriben y usan Scheme (soy uno, no un enemigo, por cierto).
  • Hay muchos intepreteres y compiladores Scheme existentes y no hay necesidad de tener uno nuevo.
  • No hay un beneficio inmediato y claro para escribir un intérprete nuevo usando LLVM. ¿Sería más rápido, más fácil, más flexible, mejor de alguna manera que las otras docenas de implementaciones de Scheme?
  • El proyecto LLVM fue con otro idioma (C) para probar su tecnología, y no se vio la necesidad de implementar muchos otros.

Creo que podría ser muy divertido para alguien construir un compilador Scheme basado en LLVM. Los compiladores de Scheme en SICP y PAIP son buenos ejemplos.

LLVM proporciona mucho, pero todavía es solo una pequeña parte del tiempo de ejecución que necesita un lenguaje funcional. Y las llamadas C FFI no son complicadas porque LLVM deja la gestión de la memoria a cargo de otra persona. Interactuar con Garbage Collector es lo que hace que las llamadas de FFI sean difíciles en lenguajes como Scheme.

Puede que le interese HLVM , pero todavía es más que experimental en este punto.

Tal vez estoy malinterpretando por completo la pregunta o el contexto, pero creo que podría usar ECL , que es un Common Lisp que compila hasta C, y usar el compilador Clang para apuntar a LLVM (en lugar de GCC).

No estoy seguro de qué beneficio (si hay alguno) le daría, pero le daría un Lisp corriendo en LLVM =].

Una cosa a tener en cuenta es que muchas de estas implementaciones tienen C FFIs y compiladores de código nativo que son significativamente anteriores a LLVM.

CL-LLVM proporciona enlaces Common Lisp para LLVM. Toma el enfoque FFI, en lugar de intentar generar el ensamblaje LLVM o el código de bits directamente.

Esta biblioteca está disponible a través de Quicklisp.

mocl es un compilador de un subconjunto relativamente estático de Common Lisp. Compila a través de LLVM / Clang.