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

Question

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

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

Вот некоторые функции, которые я надеюсь использовать для переноса:

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

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

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

Answer 1

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

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

• CLR:

  • Pro: промышленная поддержка
  • Con: вы должны купить их систему типов почти полностью; в зависимости от того, что вы хотите сделать с типами, это может не иметь значения
  • Con: Только платформа Windows действительно качественная в прайм-тайм

• LLVM:

  • Pro: восторженное сообщество пользователей с харизматичным лидером
  • Pro: серьезная поддержка от Apple
  • Pro: много интересных улучшений производительности
  • Con: довольно сложный интерфейс
  • Con: история дыр в технике; поскольку LLVM созревает, ожидайте, что дыры в разработке будут закрыты, добавив к сложности интерфейса

• C -

  • Pro: цель - это настоящий письменный язык, а не 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--.

Answer 2

про / минусы:

• CLR:

  • pro: среда CLR легко доступна; много вещей, которые можно связать с
  • con: привязано к CLR (;-); нацеливание на некоторые системы будет трудным или невозможным (встроенные, мэйнфреймы и т. д. Значение CLR может быть менее зрелым в системах без MS)

• LLVM:

  • pro: не зависит от MS.
  • con: нацеливание на некоторые системы может включать перенос LLVM (?); Взаимодействие с DOT-сетью, Java и т. д. может быть проблематичным (возможно, требуется FFI)

• C в качестве целевого языка:

  • pro: почти все цели возможны; легкая генерация кода
  • con: вам нужно будет реализовать некоторые виртуальные вещи как библиотеку времени выполнения (GC, dynload, dyn-компиляция и т. Д.); некоторые вещи трудно сделать в C (продолжения, обратный трекинг, трассировка стека, исключения); некоторые вещи трудно сделать эффективно и переносимо в C (GC, динамические типы, зависимость от макета стека).

• Java ByteCode в качестве цели:

  • pro: вероятно, самый большой набор возможных целевых платформ (даже мобильные телефоны и встроенные устройства); много существующих инструментов вокруг; простой интерфейс к существующим библиотекам
  • con: некоторые вещи сложно или сложно реализовать эффективно (динамические типы, продолжения, возврат)

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

РЕДАКТИРОВАТЬ: на самом деле ответ на комментарий, но 300 знаков недостаточно.

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

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

Answer 3

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

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