+1 реализация CL

Видел анонс этого чуда на #lisp несколько месяцев назад. Идея перепилить ECL на LLVM вместо GCC на поверхности же лежала, удивлён, что этим давно не занялись сами разработчики ECL.

Посмотрим, но... пессимизма в отношении будущего этого проекта у меня больше, чем «радужных надежд».

Взаимодействие CL - С++ может кому и жизненно необходимо, но вопрос остаётся в оптимизации «перехода» от «полу-динамики» CL к статике C++. В ECL не всё хорошо - генерируемый код сильно уступает тому-же sbcl по скорострельности, и оптимизации llvm здесь не спасут.

и оптимизации llvm здесь не спасут

Откуда такое мнение?

foreign C++-библиотеками

разве их так много?

Откуда такое мнение?

Из чтения си-кода, порождаемого ECL

Из чтения си-кода, порождаемого ECL

Подтверждаю. Но автор заявляет, что у него полностью свой компилятор. Так что надежда есть.

Ну да, надежда пока есть :) Если у него получится embedded CL «лучше», чем ECL - честь и хвала ему :)

разве их так много?

нет, но те, что есть, иногда написаны так, что от перспективы написания «полноценного» враппера шерсть встаёт дыбом даже на надетой ушанке

как по мне, за универсальные библиотеки без готового C-интерфейса нужно бить тапком

как по мне, за универсальные библиотеки без готового C-интерфейса нужно бить тапком

будешь бить - меня позови, помогу :)

И даже первый претендент есть - то самый llvm: сишный интерфейс в нём сделан хорошо если на 50%

будешь бить - меня позови, помогу

и меня! :)

Думаю ничего вкусного не ожидается. Взаимодействие с C++ без темплейтопарсера не имеет особой ценности — все равно ручной работы вагон по написанию врапперов. Хотя, будем надеяться на лучшее

И даже первый претендент есть - то самый llvm: сишный интерфейс в нём сделан хорошо если на 50%

Все, что реально нужно (создание и обход IR) там есть. Остальное тупо не нужно.

и 640 кб хватит всем... А «отжитить» и/или откомпилировать и динамически загрузить и выполнить код?

А «отжитить» и/или откомпилировать и динамически загрузить и выполнить код?

И это тоже есть (LLVMCreateExecutionEngine, etc.)

За последний год я где-то три или четыре функции нашел, которые не были покрыты в llvm-c, и всякий раз мои патчи, их реализующие, моментально принимались. Так что все там есть, а когда вдруг чего редкого не хватает, добавить элементарно.

хм, возможно надо ещё раз поковырять палочкой :) Не так давно не было

Так ocaml и haskell биндинги поверх llvm-c очень активно развиваются и используются в куче проектов. Понятно, что llvm-c должен быть уже достаточно полным для 99% задач.

одно дело - компилять, другое - недо-vm делать: брать кусочек кода (функцию и/или «лямбду»), строить IR, джитить или сразу в натив гнать (в памяти, а не тулузами через файлы), и тут-же пытаться выполнить. Вот это прау версий назад можно было делать только на плюсах, сишный интерфейс сей функциональности не покрывал.

Для JIT-а достаточно LLVMGetPointerToGlobal, причем с давно-замшелой-версии (уже года три точно как). При включенном JIT execution engine указатель будет на JIT wrapper, и попытка вызова этой функции приведет к исполнению JIT.

ты прав

пришлось напрячь память и вспомнить - что-же я не мог найти в include/llvm-c

Вспомнил: include/llvm/Support/DynamicLibrary.h, впрочем как и всё из include/llvm/Support