Лучший компилятор

У меня есть несколько языков, которые я строил в качестве переводчиков. Когда я готов принять "этот следующий шаг", какие варианты лучше всего подходят для не-родных скомпилированных форматов... каковы плюсы и минусы каждого из них?

Я искал компиляцию в CLR или LLVM и несколько раз рассматривал C-midcompile, но я не совсем уверен.

Несколько функций, которые я надеюсь получить в порт, следующие:

REPL. Один из языков, которые я создаю, поддерживает оценку уровня блока во время выполнения.
Надежные макросы. Один из языков, которые я создаю, требует возможности фильтрации через код отдельно перед токенизацией и в середине между токенированием и анализом.

Хорошо, не совсем "несколько", всего два. Мне нравится думать, что я могу переносить любые другие функции, поддерживаемые моими языками "ничего".

Каковы мои лучшие варианты и их плюсы и минусы?

Ответ 1

про/минусы:

CLR:
- pro: среда CLR доступна; много материала для привязки к
- con: привязан к CLR (;-); нацеленность на некоторые системы будет сложной или невозможной (встроенные, мэйнфреймы и т.д. CLR impl. может быть менее зрелым в системах без MS).
LLVM:
- pro: независимо от MS.
- con: назначение некоторых систем может включать перенос LLVM (?); взаимодействие с DOT-сетью, Java и т.д. может быть проблематичным (возможно, требуется FFI).
C как целевой язык:
- pro: возможны почти все цели; простое генерирование кода
- con: вам нужно будет реализовать некоторый материал VM как библиотеку времени исполнения (GC, dynload, dyn compilation и т.д.); некоторые вещи трудно сделать в C (продолжения, откат, трассировка стека, исключения); некоторые вещи трудно сделать эффективно и переносимыми в C (GC, динамические типы, зависимость компоновки стека).
Java ByteCode как цель:
- pro: возможно, самый большой набор возможных целевых платформ (даже мобильные телефоны и встроенные материалы); множество существующих инструментов; легкое взаимодействие с существующими библиотеками
- con: некоторые вещи трудно реализовать или трудно реализовать эффективно (динамические типы, продолжения, обратное отслеживание)

Из всего вышеизложенного, я думаю, что нацеливание на Java ByteCode, вероятно, было бы лучше для вас.

EDIT: на самом деле ответ на комментарий, но 300chars недостаточно.

JByteCode iffy - я согласен (будучи Smalltalker, JBytecode слишком ограничивает меня).

VM-wise, я думаю, что существует довольно широкий диапазон производительности, который вы можете получить как JVM, начиная с чистых медленных интерпретаторов байт-кода до высокотехнологичных JITting VM (IBM). Думаю, CLR VM наверстает упущенное, так как MS рано или поздно ворует и интегрирует все инновации, а также публикуются методы ускорения динамического перевода (например, "Self-документы" ). LLVM, вероятно, продвинется немного медленнее, но кто знает. С помощью C вы можете бесплатно использовать лучшие компиляторы, но такие вещи, как динамическая ретрансляция и т.д., Трудно реализовать с помощью C как цели. В моей собственной системе используется смесь предварительно скомпилированного и динамически скомпилированного кода (имеющего все: медленный интерпретатор байт-кода, JITter и предварительно скомпилированный статический C-код в одном пространстве памяти).

Ответ 2

Генерация кода - это мое дело: -)

Комментарии по нескольким параметрам:

CLR:
- Pro: промышленная поддержка
- Con: вам нужно полностью купить их систему типов; в зависимости от того, что вы хотите делать с типами, это может не иметь значения.
- Con: Только платформа Windows - это действительно первоклассное качество.
LLVM:
- Pro: энтузиазм сообщества пользователей с харизматическим лидером
- Pro: серьезная поддержка Apple.
- Pro: многие интересные улучшения производительности.
- Con: несколько сложный интерфейс
- Con: история дыр в технике; поскольку созревание LLVM ожидает, что дыры в инженерной сети будут подключены, добавив к сложности интерфейса
C--
- Pro: target - это настоящий письменный язык, а не API; вы можете легко проверить, отладить и отредактировать свой код C
- Pro: дизайн достаточно зрелый и разумно чист.
- Pro: поддерживает точную сборку мусора
- Pro: большинство пользователей сообщают, что очень легко использовать
- Con: очень маленькая команда разработчиков.
- Con: с начала 2009 года поддерживает только три аппаратные платформы (x86, PPC, ARM)
- Con: не поставляется с сборщиком мусора
- Con: у проекта нет будущего
C как целевой язык
- Pro: выглядит просто.
- Con: почти невозможно получить достойную производительность.
- Con: в конечном итоге вы будете использовать гайки; спросите длинную линию людей, которые пытались скомпилировать Haskell, ML, Modula-3, Scheme и другие, используя эту технику. В какой-то момент каждый из этих людей сдался и построил свой собственный генератор кода.

Сводка: ничего, кроме C, является разумным выбором. Для наилучшего сочетания гибкости, качества и ожидаемого долголетия я, вероятно, рекомендую LLVM.

Полное раскрытие: я присоединен к проекту C.

Ответ 3

LLVM кажется многообещающим. Команда претендует на лучшие результаты во время исполнения на gcc со своим backend по сравнению с родным. Возможность компиляции из AST действительно интересна (посмотрите на учебник). Он может компилировать и оптимизировать во время выполнения, что является обязательным для динамического. Он также может работать как чистый интерпретатор.

Я рассматриваю использование LLVM в проекте, который предполагает создание Tcl-подобного языка. Tcl сильно динамичен, поэтому я не знаю, что это подразумевает на данном этапе, но я уверен, что получаю лучшие результаты, чем текущее ядро на основе байт-кода.