Вышел LLVM 2.2

феерично

метка "коПМиляторы" - это сильно :)

Кто-нибудь пользовал? Какие впечатления?

не понял, а что с этим низкоуровневым представлением делать?

>> поддержка типа long double на x86/x86_84 (80 бит) и Darwin PPC/PPC64 (128 бит)

А long long double сколько еще ждать ? и еще версия 2.2 ...

> а что с этим низкоуровневым представлением делать

генерировать из других языков (например, из языка шейдеров OpenGL, как это будет делать следующая версия Mesa), а потом переводить в код x86

> а потом переводить в код x86

Или не x86.

"static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha and SPARC architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors."

> А long long double сколько еще ждать ? и еще версия 2.2 ...

А нахрена?

Что за x86_84?

>А нахрена? А чтобы точнее PI показывать :)

frontend'ы есть не только для C/C++, но и для Objective C, Ada, Fortran, Python, Stacker, Java и Scheme. В разработке LLVM D Compiler. Может есть еще для чего...

А что, компилеры в нативный код нынче уже не в моде? Лавры дот-нета спать не дают?

> А что, компилеры в нативный код нынче уже не в моде?

man Gallium3D

http://feeds.feedburner.com/~r/Phoronix/~3/230435446/vr.php :

> Gallium3D now uses LLVM (Low Level Virtual Machine) for compiling and accelerating shaders, any programming language could be put on the GPU with "minimal effort."

Шоман, ну осиль уже spellchecker к браузеру прикрутить!

Почему в новости не указана лицензия?! Мне что поссылкам ходить?! Совсем ньюсмейкеры охренели!

> Почему в новости не указана лицензия?! Мне что поссылкам ходить?! Совсем ньюсмейкеры охренели!

есть в репозитории убунты. Следовательно, по крайней мере, GPL-совместимая

> frontend'ы есть не только для C/C++, но и для Objective C, Ada, Fortran, Python, Stacker, Java и Scheme.

Т.е. вместо javac можно будет собрать прямо в промежуточный код, из которого преобразовать затем в нативный?

Хочу собраться Eclipse для Cell :D

> frontend'ы есть не только для C/C++, но и для Objective C, Ada, Fortran, Python, Stacker, Java и Scheme.

Лучше бы ты схему не вспоминал. Мало того, что сам компилятор - на mzscheme, так ещё реализовано настолько "узкое" подмножество языка, что о том чтобы сам себя сделал можно и не мечтать...

И к тому-же, данная "схема" не типизирована - итог: "в сад"!

> Т.е. вместо javac можно будет собрать прямо в промежуточный код, из которого преобразовать затем в нативный?

Совсем наоборот :)

https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt

>Darwin PPC/PPC64 (128 бит)

http://ru.wikipedia.org/128-bit ? :)

А есть сравнение производительности с gcc?

Поищи - попадаются. Как сравнение скорости компиляции, так и выполнения полученной проги. По обоим параметрам llvm вроде впереди (а иначе зачем бы результат публиковать :), но у него есть один существенный минус: заточка под него большого проекта - всё равно что под отдельную платформу.

А на нем КС работает?

> А что, компилеры в нативный код нынче уже не в моде? Лавры дот-нета спать не дают?

Не совсем корректное сравнение. И Сановский и Микро$офтовский байткоды интерпретируются или JIT компилируются. Очень редко AOT компилируются. Они не предназначены для AOT компиляции. LLVM не просто так назвали Low Level VM. Прежде всего были написаны компиляторы из LLVM в машинный язык, а потом уже VM с JIT Compiler'ом.

а можно там присобачить gc к цепепе, например?

> Прежде всего были написаны компиляторы из LLVM в машинный язык, а потом уже VM с JIT Compiler'ом.

В результате чего llvm чаще используется как альтернативный си-компилятор, а именно vm почти не используется - библиотека "из коробки", мягко говоря, _очень скромная_. И это таки получаются "два разных си".

http://llvm.org/docs/GarbageCollection.html

> библиотека "из коробки", мягко говоря, _очень скромная_

Нужно дать ему немного времени на развитие. Повезет - все будет. Не повезет - gcc не так уж плох.

> Шоман, ну осиль уже spellchecker к браузеру прикрутить!

Ты что! Ты разве не знал, что настраивать что-то под МакОсью неджобсоугодно? А уж тем более, "прикручивать". Этим только красноглазые линуксойды-нищеброды занимаются :-)

>А что, компилеры в нативный код нынче уже не в моде? Лавры дот-нета спать не дают?

Ты когда-нибудь удосуживался выяснить, как работают оптимизирующие компиляторы? Да тот же GCC? Так вот, значительная часть оптимизации происходит на уровне p-кода.

Плядь, мало того что новости вечно с ошибками, теперь еще и теги

> Ты когда-нибудь удосуживался выяснить, как работают оптимизирующие компиляторы? Да тот же GCC? Так вот, значительная часть оптимизации происходит на уровне p-кода.

Не-а :D P-код - это код абстрактной машины, а оптимизация в GCC производилась раньше над RTL (который _не является_ P-кодом), а сейчас - над GENERIC/GIMPLE, который тоже не является P-кодом (это древовидное представление программы, AFAIK).

вещага так ниче, но вот какого х.. она не LGPL, библиотека же. Придурки. зы. на самом деле ее мало кто пользует. разве что в эппл.

так, как я понимаю, llvm можно рассматривать как c-компилятор, со своим оптимизатором. а где бы бенчи результатов компиляции llvm vs. gcc посмотреть?

> Нужно дать ему немного времени на развитие. Повезет - все будет. Не повезет - gcc не так уж плох.

Так речь не о си-компиляторе, а о vm как кросс-платформе для конечных приложений, а не составляющей самого компилятора. Без либ vm - 0. А развития именно vm-ных либ я и не наблюдаю.

> Ты разве не знал, что настраивать что-то под МакОсью неджобсоугодно? А уж тем более, "прикручивать"

:) в Mac OS X проверка орфографии в текстовых элементах (контролах) вообще-то изкаропки :)

>По обоим параметрам llvm вроде впереди (а иначе зачем бы результат публиковать :), но у него есть один существенный минус: заточка под него большого проекта - всё равно что под отдельную платформу.

Хм, а почему его нельзя рассматривать как альтернативный gcc компилятор (если всякие фишечки VM не использовать, просто компилить в нативный код)?

под макосью спеллчекер уже прикручен ко всем кокоа-программам из коробки (в том числе и к сафари), ничего прикручивать не надо, этим только красноглазые линуксойды-нищеброды занимаются

что-то сильно большой у них список Known problems для релиза с номером 2.2..

> Хм, а почему его нельзя рассматривать как альтернативный gcc компилятор (если всякие фишечки VM не использовать, просто компилить в нативный код)?

Почему нельзя - именно так чаще всего и используют :)

>Почему нельзя - именно так чаще всего и используют :)

Тогда непонятно, зачем затачивать? У него каких-то фич не хватает или реализованы по-другому, нежели в gcc?

надеюсь лучшие идеи войдут в gcc

> надеюсь лучшие идеи войдут в gcc

Тогда это уже будет не gcc, а gllvm.

ИМХО llvm - шаг в правильном направлении, а gcc - топтание на месте.

были же всякие EGCS которые потом слились с gcc, надеюсь и тут обкатают какие-то вещи и преобразуют gcc, идея то вроде верная

> Тогда непонятно, зачем затачивать? У него каких-то фич не хватает или реализованы по-другому, нежели в gcc?

У него "окружение" тоже собственное (линковщик и т.д.) и всё это вкупе не 100% совместимо с gcc. Как результат - "в лоб" большие программы не собираются. Посему каждый отдельный случай сборки того или иного проекта с помощью llvm на их форуме встречается с большой радостью.

В LLVM обещали interprocedural optimization, которую трудно делать. если окружение в коде целевой платформы и не может модифицироваться во время исполнения программы. В LLVM окружение находится в промжуточном предствлении, которое может быстро JIT-компилироваться в машиный код (отсюда и VM). IO дает очень неплохой выигрыш в производительности.

Вообще, LLVM задумывался как framework для разработки алгоритмов оптимизации.

>а где бы бенчи результатов компиляции llvm vs. gcc посмотреть?

http://lucille.atso-net.jp/blog/?p=294

> под макосью спеллчекер уже прикручен ко всем кокоа-программам из коробки (в том числе и к сафари), ничего прикручивать не надо, этим только красноглазые линуксойды-нищеброды занимаются

Я угадал, я угадал! :-)

Что, и на двух языках проверяет?

> А есть сравнение производительности с gcc?

http://www.youtube.com/watch?v=VeRaLPupGks

> :) в Mac OS X проверка орфографии в текстовых элементах (контролах) вообще-то изкаропки :)

Лучше бы она была из черепной каропки юзера.