Подтвердить что ты не робот

В чем причина создания LLVM?

В чем разница между LLVM и обычным компилятором?
Является ли он более динамичным и, следовательно, может быть использован для компиляции нормально динамических языков (например, Javascript) в статический двоичный код? Каковы принципы создания одного из них? Я знаю книгу Дракона для компиляторов, но есть ли такая вещь для LLVM?

EDIT: Я нашел этот интересный проект.

Ответ 1

Существует несколько различий между LLVM и "обычным компилятором", который я буду считать "gcc":

LLVM предназначен для анализа всей программы (aka link-time analysis), поэтому он может факультативно компилировать код в "биткод", формат, который он может повторно проанализировать позже.
LLVM обеспечивает компилятор "точно в срок" (JIT), чтобы он мог повторно анализировать программы во время их работы, как это делает JVM.
LLVM очень хорошо спроектирован:
- его компоненты являются модульными и хорошо разделены,
- он имеет 3 формата для своего промежуточного представления (текстовое, двоичное и представление в памяти), которые эквивалентны,
- его промежуточное представление использует форму SSA,
- его промежуточное представление имеет систему типов.

Что касается Javascript и других динамических языков, мы видим много интересного в LLVM из динамического языкового сообщества, с реализацией Python и Ruby. Однако они не пытаются быть статическими компиляторами. Они сосредоточены на использовании JIT. В частности, оптимизируются длинные исполняемые файлы с использованием "интерпретатора смешанного режима", где они первоначально интерпретируют программы, а затем компилируют их с использованием LLVM во время выполнения. Я не видел javascript-движок с использованием LLVM, но, вероятно, есть один. Он просто не будет создавать статические исполняемые файлы, за исключением необычных обстоятельств, или для сокращения версий Javascript.

Что касается причины создания LLVM, то он начинался как часть исследовательской группы Vikram Adve по составлению долгой жизни (что означает JITs и оптимизация времени соединения). После его PhD Крис Лэттнер переехал в Apple, который сильно продвигает проект (вероятно, потому, что он лицензирован BSD, что в прошлом вызывало проблемы с gcc, что является GPL).

Ответ 2

Ничто не является обычным компилятором. Его основной причиной для создания было создание платформы для исследования компилятора. Поэтому он разработан очень модульно, так что вы можете работать с той частью компилятора, которая занимается вашим исследованием, и не беспокоиться о других частях компилятора. Нет компилятора дракона, так как нет книги LLVM (любая теория, которую вы читаете в книге драконов или любой другой книге компилятора, должна быть непосредственно применима). На самом деле, пока я не заглядывал в LLVM, их документация была довольно плохой.

Ответ 3

Я вообще не разрабатываю, но: даже если gpl заставил NeXt опубликовать свою рабочую среду ObjC в 80-е годы, основной причиной для яблока для финансирования другого компилятора (GPL или нет) является его желание интегрироваться с IDE. GCC доказал, что в этой области слишком много инерции, а GCC недостаточно модульно, чтобы использовать повторное использование частей кода (функция xcode "исправить" ). То, что я понял из моих чтений