Лучшее место назначения компилятора

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

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

за / против:

• CLR:

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

• LLVM:

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

• C как целевой язык:

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

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

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

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

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

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

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

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

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

• CLR:

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

• LLVM:

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

• C--

  • Плюсы: target - это реальный письменный язык, а не API; вы можете легко проверять, отлаживать и редактировать свой код C--
  • Плюсы: дизайн достаточно зрелый и достаточно чистый.
  • Pro: поддерживает точную сборку мусора
  • Плюсы: большинство пользователей сообщают, что им очень легко пользоваться.
  • Минус: очень маленькая команда разработчиков
  • Минусы: по состоянию на начало 2009 года поддерживает только три аппаратные платформы (x86, PPC, ARM).
  • Минус: не поставляется со сборщиком мусора.
  • Минус: у проекта нет будущего

• C как целевой язык

  • Плюс: выглядит просто
  • Минус: практически невозможно получить достойную производительность
  • Против: сведет вас с ума в долгосрочной перспективе; спросите длинную очередь людей, которые пытались скомпилировать Haskell, ML, Modula-3, Scheme и другие, используя эту технику. В какой-то момент каждый из этих людей сдался и построил собственный генератор нативного кода.

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

Полное раскрытие информации: я связан с проектом C--.