Релиз LLVM 2.9

> (Почитай про функции виртуальной машины, прежде чем писать подобную ересь).

Батенька, да вы, похоже, дурак. GIMPLE в GCC - это тоже, представь себе, виртуальная машина. Тоже отправишь меня читать?

> Да нету там виртуальных машин, хоть ты тресни! Исполнения приложения во время компиляции не происходит.

Хоть обтрескайся, но там полно виртуальных машин. На каждый уровень компиляции по виртуальной машине. В LLVM она хотя бы одна (ну ладно, две - SSA и то, что после reg2mem остается), а в GCC виртуальных машин полно.

LLVM же является виртуальной машиной с байт-кодом и JIT-ом

Ты болеешь, да? Головой сильно стукнулся? Где тут байт-код и JIT?

$ clang -S hw.c
$ cat hw.s
        .def     _main;
        .scl    2;
        .type   32;
        .endef
        .text
        .globl  _main
        .align  16, 0x90
_main:                                  # @main
# BB#0:                                 # %entry
        pushl   %ebp
        movl    %esp, %ebp
        subl    $16, %esp
        movl    $0, -4(%ebp)
        movl    %esp, %eax
        movl    $L_.str, (%eax)
        calll   _printf
        movl    %eax, -8(%ebp)          # 4-byte Spill
        movl    -4(%ebp), %eax
        addl    $16, %esp
        popl    %ebp
        ret

        .data
L_.str:                                 # @.str
        .asciz   "Hello, world!\n"

> Ладно для интерпретируемых языков, а какая выгода от промежуточного представления для какого-нибудь С? Хоть ссылкой ткните, если это где-то хорошо разжевано.

http://www.ozon.ru/context/detail/id/3829076/

> К.О: LLVM же. Сначала загрузчик ее грузит, а потом она уже загружает приложение. Причем, второй процесс куда тяжелее первого.

Ну вперед, с песнями, ищи LLVM в бинарниках, созданных llc.

>> Чего он может. менять порядок следования инструкций? которые в памяти.

Да. Поправьте если ошибаюсь. As a kind of proof — Роберт Лав, Linux Kernel Development, глава 10, «Ordering and Barriers» и глава 19, «Processor Ordering».

Между барьерами может

Ну да. Т.е. иногда/часто может.

> Ну и в чем, по твоему, разница между LLVM и GIMPLE? Одинакового уровня прослойки.

Gimple не участвует в исполнении приложения. Если использовать LLVM как виртуальную машину, а не как компилятор, то прослойка при исполнении все-таки есть.

Ваш К.О.

> Ну вперед, с песнями, ищи LLVM в бинарниках, созданных llc.

То же касается авторов постов http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6144794 http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6144772 http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6144772 (последние два еще и интерпретатор в GCC узрели...): Перед тем, как встревать в спор, сначала посмотрите, с чего он начался - http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6128623

> Gimple не участвует в исполнении приложения.

Точно так же как и LLVM.

Если использовать LLVM как виртуальную машину, а не как компилятор, то прослойка при исполнении все-таки есть.

Повторяю для особенно тупых: ты не понимаешь вообще, что такое виртуальная машина. У тебя в голове каша. Ты путаешь виртуальную машину с интерпретатором или JIT-ом виртуальной машины. На самом деле виртуальная машина - это абстрактная семантика. И между LLVM и GIMPLE никакой разницы нет в принципе. И то и другое это виртуальные машины, описывающие некий, достаточно низкий (и машинозависимый) уровень. И для того, и для другого существуют компиляторы в разнообразные native ассемблеры. И тот и другой компилятор можно прикрутить для кодогенерации в памяти - тогда получится что-то типа JIT-а. Просто с LLVM это делают чаще, чем с GCC, он для этого немного удобнее. Вот и вся разница.

> последние два еще и интерпретатор в GCC узрели...

Больной и тупой, да?

Он там есть, не хуже чем в LLVM. И используется там интерпретатор ровно с той же целью - агрессивный constant propagation.

> с чего он начался - http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6128623

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

> Ты путаешь виртуальную машину с интерпретатором или JIT-ом виртуальной машины.

http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C...

Для нелюбителей ходить по ссылкам цитирую: «Виртуальная машина исполняет некоторый машинно-независимый код». ИСПОЛНЯЕТ. Понятно?

а самом деле виртуальная машина - это абстрактная семантика.

Да и не логично это вовсе - называть «машиной» семантику кода.

между LLVM и GIMPLE никакой разницы нет в принципе. И то и другое это виртуальные машины

Расскажите это авторам GIMPLE - вот они удивятся!

> Он там есть, не хуже чем в LLVM. И используется там интерпретатор ровно с той же целью...

Интерпретатор в компиляторе... \0

> Для нелюбителей ходить по ссылкам цитирую: «Виртуальная машина исполняет некоторый машинно-независимый код». ИСПОЛНЯЕТ. Понятно?

Не пойти ли тебе на хер со ссылками на педиковикию? То, что статью писали сосунки, про эту их новомодную «виртуализацию», которая еще десять лет назад вообще никому никуда не впилась, это как бы не важно, да?

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

Да и не логично это вовсе - называть «машиной» семантику кода.

Ну давай, иди, поучи Ахо с Ульманом, что им и как называть. Ты ж типа самое умное тут, а они все погулять вышли.

Расскажите это авторам GIMPLE - вот они удивятся!

Я поражаюсь, как такое необразованное чмо может обладать таким упертым апломбом.

> Интерпретатор в компиляторе...

Именно так, наивный человек, именно так. Почитай уж, как работают такие оптимизации, как Agressive DCE, global DCE, agressive constant propagation и partial specialisation. Все они основаны на частичной интерпретации выражений или последовательностей инструкций VM.

Кстати, вот тебе еще для разрыва шаблона - в GCC еще и байткод есть, все как у взлослых. Читай про LTO.

> Практически не существует компиляторов, внутри которых не было бы виртуальной машины.

Может, для таких упоротых анонимусов хоть бан по IP предусмотрен...

Тем, кто хочет продолжить пороть такую ересь, предлагаю сначала почитать ту же педивикию:

http://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B0%D0%BD%D1%81%D0%BB%D1%8F%D1%82...

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%B5...

Ресурс хоть и не самый достоверный, но все-же более корректный чем чье-то ИМХО...

По второй ссылке русским по белому написано: «Интерпрета́тор — ... Вид транслятора, осуществляющего пооператорную (покомандную) обработку ... (в отличие от компилятора, транслирующего всю программу без её выполнения)». Обратите внимание на «В ОТЛИЧИЕ ОТ КОМПИЛЯТОРА» и «БЕЗ ЕЕ ВЫПОЛНЕНИЯ».

> Тем, кто хочет продолжить пороть такую ересь, предлагаю сначала почитать ту же педивикию:

Педивикия уже стала авторитетом? Ссылался бы хотя бы на Голдберга.

По второй ссылке русским по белому написано: «Интерпрета́тор — ... Вид транслятора, осуществляющего пооператорную (покомандную) обработку ... (в отличие от компилятора, транслирующего всю программу без её выполнения)». Обратите внимание на «В ОТЛИЧИЕ ОТ КОМПИЛЯТОРА» и «БЕЗ ЕЕ ВЫПОЛНЕНИЯ».

Да, идиот ты клинический. Боюсь, лечиться тебе давно уже поздно.

Повторяю для терминально больных на голову: читай о том, для чего компиляторам нужно частично интерпретировать код. Ключевые слова я тебе дал. Про это в любой относительно современной книге по компиляторам написано.

> для чего компиляторам нужно частично интерпретировать код

Да до лампочки, какую магию компилятор применяет для своей работы. Главное - на выходе полноценный пакет с нативными процессорными инструкциями, для запуска которого не требуется стороннего приложения/демона.

> Да до лампочки, какую магию компилятор применяет для своей работы. Главное - на выходе полноценный пакет с нативными процессорными инструкциями, для запуска которого не требуется стороннего приложения/демона.

Ну то есть слил, да? Молодец. А теперь усвой: LLVM это компилятор. GCC это компилятор. Между ними нет никакой архитектурной разницы. И у того, и у другого куча frontend-ов и куча backend-ов. И тот, и другой, генерят ассемблерный код, который потом отдается отдельно ассемблеру и линкеру. И тот, и другой способны интерпретировать свой промежуточный код. И LLVM и GCC можно использовать в качестве JIT, для чего просто отключается большая часть дорогостоящих оптимизаций, но это не является основным применением для них.

> Исполнения приложения во время компиляции не происходит.

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

> Давай лучше допустим, что я реализую криптоалгоритм или фильтр для изображения.

давай, давай. Вот для Lua есть реализация парсера виртуальной машиной: http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
про цифровые фильтры: DSP VM http://lantana.tenet.res.in/website_files/publications/DSPVM/standDSPVIRTUAL2...

>Кому удалось завести libc++ ? А то у меня она компилится, а компилятор её потом не видит.

-lc++ ?

ну или map-файл собрать, и убедиться, что лишних зависимостей нету или ldd ./helloworld|grep libLLVM и убедиться, что в бинарнике размером около 6kb все библиотеки LLVM размером ~15Мб не помещаются :))

> На самом деле виртуальная машина - это абстрактная семантика.

во! но апи рантайма стандартной библиотеки — это тоже абстрактная семантика АБИ программы на каком-то языке. То есть, разница между рантаймом стандартной библиотеки языка и виртуальной машиной языка (например, интерпретатором) только в уровне этой абстрактной семантики — ниже какого-то уровня это ещё рантайм, выше какого-то метауровня это уже виртуальная машина. Если ещё считать что при этом и языки меняются (язык для интерпретатора <=> подмножество языка для компиляции <=> подмножество метаязыка (языка виртуальной машины компилятора) (то есть, ищется неизвестная виртуальная машина неизвестного метаязыка, которым по сути является АБИ программы), то для произвольной программы нельзя наугад ткнуть пальцем и сказать, где заканчивается виртуальная машина и начинается уже рантайм.
Хотя для обычных случаев оно всё-таки гораздо чётко выделено.

> Для нелюбителей ходить по ссылкам цитирую: «Виртуальная машина исполняет некоторый машинно-независимый код».

ты сам-то свою ссылку читал?

http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C...

также, спецификация некоторой вычислительной среды (например: «виртуальная машина языка программирования Си»).

ИСПОЛНЯЕТ. Понятно?

и что, тебе непонятно какой тут язык исполняется, чем именно и в какой момент трансляции?

Да и не логично это вовсе - называть «машиной» семантику кода.

пипец. А это по-твоему что http://en.wikipedia.org/wiki/SECD_machine ? только не говори, что семантика тут не причём.

>> а самом деле виртуальная машина - это абстрактная семантика.

Да и не логично это вовсе - называть «машиной» семантику кода.

как раз логично — взяли операционную семантику языка и выделили её в виде виртуальной машины. Взяли исполнили программу на этой виртуальной машине — получили интерпретатор. Взяли прогнали (man РЕФАЛ прогонка суперкомпиляция) интерпретатор через суперкомпилятор => сделали компилятор. Ну или без суперкомпилятора, проинтерпретировали интерпретатор другой транслирующей машиной, более простой => получили компилятор.

Это если явно семантику кода определять, можно явно сказать: вот она, семантика, реализуется виртуальной машиной. А если эта семантика не такая явная, сама получена из другой виртуальной машины — можно сказать это рекурсивные виртуальные машины, вложенные друг в друга, и программа, апи в конкретных деталях вплоть до аби и исполнения, виртуальная машина — это одно и тоже, только с разных точек зрения (логических уровней. Физически код-то тот же самый, как ни смотри).

> Интерпретатор в компиляторе... \0

начнём с С++. напиши факториал шаблонами, и скажи мне, как без интерпретора (языка шаблонов) может завершиться и отработать конпелятор (языка С++)?

потом можно будет к С перейти. Например, почему gcc -m32 и gcc -m64 транслируют int или void* в разное количество байтов? вот есть у меня структура из int-ов и указателей, как мне узнать во время комиляции сколько байтов она займёт и конкретно где, учитывая выравнивание?

> Главное - на выходе полноценный пакет с нативными процессорными инструкциями,

а ты ещё и про микрокод процессора небось совсем не знаешь?
нативные инструкции такие нативные

> GCC это компилятор. Между ними нет никакой архитектурной разницы.

ну, архитектурная разница есть. Она в способе структурирования модулей: у gcc это отдельные программы (cpp, cc1, as, ld который в свою очередь обёртка над collect2), связанные через пайпы кодом в универсальной форме (что по Э.Реймонду Art Of the Unix Programming есть TrueЪ), в итоге имеем понятные данные и код, в котором относительно сложно разобраться.
в LLVM это АПИ библиотек на С++, которые разбиты на модули, реентерантны и сидят в виде библиотек в памяти. Всё что нужно — дёргать за API вызовы, не нужно столько обёрток.

параллелизм по данным / параллелизм по коду типа

И LLVM и GCC можно использовать в качестве JIT,

а как сделать GCC-JIT?

> И тот, и другой, генерят ассемблерный код, который потом отдается отдельно ассемблеру и линкеру.

ЕМНИП, clang может генерировать бинарник напрямую в обход ассемблера, если его об этом специально не просить — работает с биткодом в памяти напрямую, не передавая его в стороние тулзы, вроде tcc через libtcc

Как написать свой игрушечный компилятор на Flex, Bison и LLVM http://gnuu.org/2009/09/18/writing-your-own-toy-compiler/

ещё интересная идея здесь http://piumarta.com/S3-2010/ : компилятор, в котором в качестве и фронтенда и бекенда используется PEG парсер. Язык вроде Scheme транслируется в ассемблер x86, в статье описано представление, упрощающее трансляцию. Производительность оттранслированного в районе 75% от GCC, с парой тривиальных описанных в статье оптимизаций в районе 80-95% от того же кода, собранного GCC.

компилятор простой, на пару страниц.

Что интересно было бы сделать: прикрутить к этому компилятору трансляцию в SSA форму и LLVM в итоге, и использовать LLVM для оптимизаций (отдельно генерируя биткод и запуская opt) и окончательной кодогенерации.

Инклуды оно не видит.

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

> Она в способе структурирования модулей: у gcc это отдельные программы (cpp, cc1, as, ld который в свою очередь обёртка над collect2), связанные через пайпы кодом в универсальной форме (что по Э.Реймонду Art Of the Unix Programming есть TrueЪ), в итоге имеем понятные данные и код, в котором относительно сложно разобраться.

LLVM тоже бывает в виде кучки отдельных бинарников - opt, llc, llvm-link, и т.д. И gcc при желании можно в один большой бинарник собрать.

а как сделать GCC-JIT?

Это довольно таки жуткое извращение, конечно же. Я подменял драйвер (cc1) своей оберткой. Правда, без промежуточных ассемблерных файлов и пайпа к gas не обошлось, но jit был примерно как TCC устроен.