Здравствуйте, Went, Вы писали:
W>Можно будет сделать С++ — компилятор частью программы и компилировать С++ — код на лету?
Нет. То есть сделать это ты, конечно, можешь, но libgccjit тут никоим образом участвовать не будет и не поможет.
libgccjit — это библиотека доступа к backend'у компилятора. То есть на вход она получает нечто похожее на AST, а на выходе даёт машинный код под конкретную платформу.
Если же хочется компилировать C++, то тебе нужна frontend часть компилятора, которая собственно переведёт код из C++ в вид понятный backend части. Написание своего C++-frontend это, конечно, крайне сложная задача. Заточить уже существующий проще, но тоже потребует усилий. То есть ни того, ни другого варианта в готовом виде не существует и в непосредственном будущем существовать не будет.
Если уж стоит задача именно в динамической компиляции C++ кода, то разумнее всего взять просто полноценный компилятор (в standalone варианте, или завёрнутый в библиотеку) и запускать его. Это совершенно прямолинейный подход, но от этого получаемый результат не станет хуже.
Так что цель libgccjit не в том чтобы компилировать C++ код, а в том чтобы облегчить создание компиляторов, предоставив уже готовый backend. То есть, как и сказано в описании, если у тебя уже есть готовый frontend для своего языка, или виртуальная машина для какого-то своего байт-кода, и ты хочешь её ускорить, воспользовавшись наработками gcc, то эта библиотека — твой выбор.
Другой аналоги — это, например, llvm, который также умеет переводить описание программы из промежуточного кода в машинный. Ну и в некотором роде к аналогам можно добавить ещё и pypy, запущенный в режиме создания компилятора, а не в режиме одноимённого интерпретатора питона. Он тоже может создать по описанию виртуальной машины её jit версию, хотя там несколько другой подход.
W>А как его потом линковать с основной программой?
Динамически. Это просто вызов функции по указателю.
В результате компиляции будет просто получен контейнер с машинным кодом функций с одной или несколькими точками входа. Их вызов из основной программа как раз приведёт к выполнению той логики, которая была передана исходно в libgccjit. Работа идёт точно так же, как и при импорте функций из динамических библиотек с использованием, например, dlsym или GetProcAddress.
Ну и в режиме Ahead-of-Time можно сразу получить ту же .so, чтобы не компилировать программу каждый раз заново, а просто положить результат в файл и загружать функциями ОС (вроде уже упомянутых dlsym и GetProcAddress) без использования gcc.
Выходящий скоро gcc 5.0 можно будет использовать как JIT.
libgccjit
New in GCC 5 is the ability to build GCC as a shared library for embedding in other processes (such as interpreters), suitable for Just-In-Time compilation to machine code.
The shared library has a C API and a C++ wrapper API providing some "syntactic sugar". There are also bindings available from 3rd parties for Python and for D.
For example, this library can be used by interpreters for compiling functions from bytecode to machine code.
The library can also be used for ahead-of-time compilation, enabling GCC to be plugged into a pre-existing frontend. An example of using this to build a compiler for an esoteric language we'll refer to as "brainf" can be seen here.
libgccjit is licensed under the GPLv3 (or at your option, any later version)
It should be regarded as experimental at this time.
Здравствуйте, Went, Вы писали:
W>А если я, например, предкомпильну на своей машине С++ — скрипт в AST-код (при помощи того же GCC), то он уже под машину сможет построить машинный?
Да. Но есть один нюанс — gcc не умеет компилировать в ast, совместимый с libgccjit
Если хочется делать так прямо сейчас, то возьми clang и llvm. Первый скомпилирует C++ программу в IR, второй перегонит IR в машинный код.
W>А как быть с функциями, вызываемыми ИЗ скомпиленного? Там какую-то таблицу заполнить надо будет?
Вызываешь gcc_jit_context_new_function с флагом GCC_JIT_FUNCTION_IMPORTED. Это аналог extern из C/C++. При загрузке кода соответствующая функция будет взята из вызывающей программы.
Здравствуйте, VTT, Вы писали:
VTT>Это что же получается, "компиляторы для эзотерических языков" на основе этой библиотеки сделать можно будет, а компилятор для старого доброго C — нет?
Просто — не сделать. Можно только на общих основаниях с другими нереализованными эзотерическими языками написать свой транслятор из С в пригодный для передачи в libgccjit вид.
Впрочем, предполагается, что в этом нет никакого смысла. Если тебе нужен c-frontend и нужен gcc-backend, то нет никаких причин не вызывать gcc напрямую — он с этой задачей справляется куда лучше. Да и, очевидно, ждать выхода gcc5 для этого тоже не нужно.
А от libgccjit тут пользы никакой не будет. Это ведь довольно утилитарная вещь, полезная лишь разработчикам компиляторов и интерпретаторов — им она, конечно, сильно облегчит жизнь в некоторых сценариях. И их восторг понятен. Почему же другие разработчики радуются наличию jit уже не так ясно. Наверное всё-таки из солидарности со своими коллегами. Ведь не может же быть так, что они не прочли документацию и не знают что же именно скрывается за красивым словом jit Это я к тому, что есть много разных технологий, объединённых за общим словом jit, и кажется, что эту конкретную реализацию иногда путают с чем-то другим.
Здравствуйте. Вроде и читаю, а главного не пойму. Можно будет сделать С++ — компилятор частью программы и компилировать С++ — код на лету? А как его потом линковать с основной программой?
Здравствуйте, Шахтер, Вы писали:
Ш>Выходящий скоро gcc 5.0 можно будет использовать как JIT.
Эх, я-то понадеялся, что в С++ добавят хитрый способ инстанцировать шаблоны во время выполнения да еще с оптимизацией под текущее железо. А C код и сейчас можно легко на лету компилировать и выполнять. Полноценный (?) gcc для таких целей конечно будет полезен, но ничего принципиально нового тут нет.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Abyx, Вы писали:
Ш>>Выходящий скоро gcc 5.0 можно будет использовать как JIT. A>нафига? в ллвм-то же попробовали использовать JIT и вроде отказались
Кто чего отказался?
Здравствуйте, VTT, Вы писали:
VTT>А C код и сейчас можно легко на лету компилировать и выполнять. Полноценный (?) gcc для таких целей конечно будет полезен, но ничего принципиально нового тут нет.
Забавный факт: анонсированная библиотека не умеет компилировать C. Так что насчёт "ничего принципиально нового тут нет" это очень точно подмечено
А если серьёзно, библиотека просто служит другой цели — дать доступ к backend'у компилятора.
Здравствуйте, watchmaker, Вы писали:
W>Забавный факт: анонсированная библиотека не умеет компилировать C. Так что насчёт "ничего принципиально нового тут нет" это очень точно подмечено W>А если серьёзно, библиотека просто служит другой цели — дать доступ к backend'у компилятора.
Это что же получается, "компиляторы для эзотерических языков" на основе этой библиотеки сделать можно будет, а компилятор для старого доброго C — нет?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, watchmaker, Вы писали:
W>Нет. То есть сделать это ты, конечно, можешь, но libgccjit тут никоим образом участвовать не будет и не поможет.
W>libgccjit — это библиотека доступа к backend'у компилятора. То есть на вход она получает нечто похожее на AST, а на выходе даёт машинный код под конкретную платформу. W>Если же хочется компилировать C++, то тебе нужна frontend часть компилятора, которая собственно переведёт код из C++ в вид понятный backend части. Написание своего C++-frontend это, конечно, крайне сложная задача. Заточить уже существующий проще, но тоже потребует усилий. То есть ни того, ни другого варианта в готовом виде не существует и в непосредственном будущем существовать не будет.
А если я, например, предкомпильну на своей машине С++ — скрипт в AST-код (при помощи того же GCC), то он уже под машину сможет построить машинный?
W>В результате компиляции будет просто получен контейнер с машинным кодом функций с одной или несколькими точками входа. Их вызов из основной программа как раз приведёт к выполнению той логики, которая была передана исходно в libgccjit. Работа идёт точно так же, как и при импорте функций из динамических библиотек с использованием, например, dlsym или GetProcAddress.
А как быть с функциями, вызываемыми ИЗ скомпиленного? Там какую-то таблицу заполнить надо будет?
Здравствуйте, Шахтер, Вы писали:
Ш>Выходящий скоро gcc 5.0 можно будет использовать как JIT.
Круто конечно, в некоторых случаях.
Но вот давайте подумаем. Если брать только Desktop то практически процессоров без SSE/SSE2 сейчас найти очень сложно.
По карйней мере у меня еще никто не жаловался что приложение не запускается, так что смело компилирую с использованием интринсиков и оптимизацией для SSE.
Ну вот правда у самого есть i7 5960X, туда вроде еще какую то более крутую систему команд запихнули, и это положтельная сторона JIT-а если конечно он способен будет.
Другая сторона это то что теперь код будет храниться в бинаре в более простом (не оптимизированном) IR для того что бы JIT на лету мог это переварить в высоко оптимизированный нативный код.
Но в то же самое время это упрощает "дизассемблирование" такого кода, чуть ли не до сразу компилируемых исходников (для clang есть такие бекенды), так что даже HEX-Rays уже тут становится не нужным. А потом что? обсфукаторы JIT кода?
Здравствуйте, watchmaker, Вы писали:
W>Нет. То есть сделать это ты, конечно, можешь, но libgccjit тут никоим образом участвовать не будет и не поможет.
W>libgccjit — это библиотека доступа к backend'у компилятора. То есть на вход она получает нечто похожее на AST, а на выходе даёт машинный код под конкретную платформу.
W>Если же хочется компилировать C++, то тебе нужна frontend часть компилятора, которая собственно переведёт код из C++ в вид понятный backend части. Написание своего C++-frontend это, конечно, крайне сложная задача. Заточить уже существующий проще, но тоже потребует усилий. То есть ни того, ни другого варианта в готовом виде не существует и в непосредственном будущем существовать не будет.
Здравствуйте, watchmaker, Вы писали: W>>А если я, например, предкомпильну на своей машине С++ — скрипт в AST-код (при помощи того же GCC), то он уже под машину сможет построить машинный? W>Да. Но есть один нюанс — gcc не умеет компилировать в ast, совместимый с libgccjit
А есть документация на этот AST с хорошими примерами? Или пока что это все в разработке?
Здравствуйте, VTT, Вы писали:
Ш>>Выходящий скоро gcc 5.0 можно будет использовать как JIT.
VTT>Эх, я-то понадеялся, что в С++ добавят хитрый способ инстанцировать шаблоны во время выполнения да еще с оптимизацией под текущее железо.
Это было бы хорошо даже слишком, учитывая философию C++
VTT> А C код и сейчас можно легко на лету компилировать и выполнять.
Как можно С код на лету компилировать/исполнять, вы чем пользуетесь ?
