Увидел свет (http://dragonegg.llvm.org/#gettingrelease) релиз проекта DragonEgg 2.8, представляющего собой плагин к набору компиляторов GCC 4.5, заменяющий оригинальные оптимизаторы и генераторы кода GCC на аналоги, созданные в рамках проекта LLVM. DragonEgg предоставляет наиболее простой способ использования технологий LLVM без модификации кода GCC (при сборке достаточно добавить "-fplugin=path/dragonegg.so").
В настоящий момент до достаточно высокого уровня доведена работоспособность DragonEgg для языков Си и Си++ (пройден рубеж собственной пересборки), частично реализована поддержка Fortran и Ada, хуже обстоят дела с поддержкой Obj-C и Obj-C++, много работы предстоит проделать для поддержки Java. На текущей стадии развития DragonEgg поддерживает архитектуры x86-32 и x86-64, может работать в Linux и Darwin.Из улучшений, добавленных в DragonEgg 2.8, можно отметить:
- Синхронизация с кодовой базой LLVM-2.8 (http://www.opennet.me/opennews/art.shtml?num=28207);
- Сокр...URL: http://www.phoronix.com/scan.php?page=news_item&px=ODY3Mg
Новость: http://www.opennet.me/opennews/art.shtml?num=28264
и что, этот плугин оптимизит лучше чем стандартные средства gcc? не верю!
а никто этого и не утверждал (?)
llvm в плане оптимизации пока отстает от gcc... Но зато он развивается гораздо стремительнее. Не пройдет и года как gcc отправится на свалку истории. :)Кроме того llvm значительно информативнее рапортует об ошибках. Причем диагностирует больше, чем gcc. Для разработчиков очень ценное качество.
В чем смысл сабжа - не знаю :)
> Не пройдет и года как gcc отправится на свалку истории. :)А этот ваш год - это по масштабам какой планеты? Зуб даю что не планеты Земля :). Или у вас есть железная уверенность что через год LLVM будет генерить мипсовые инструкции оптимальнее гцц? :)
>> Не пройдет и года как gcc отправится на свалку истории. :)
> А этот ваш год - это по масштабам какой планеты? Зуб даю
> что не планеты Земля :). Или у вас есть железная уверенность
> что через год LLVM будет генерить мипсовые инструкции оптимальнее гцц? :)llvm сделан правильнее... gcc за ним не угонится.
FreeBSD уже отказывается от gcc - но у них мотивы другие, лицензионные.Год или не год - видно будет в конце 2011 :)
Надо где нибудь записать - то дескать великий я предсказал смерть gcc в конце 2011. :D
> мипсовые инструкции оптимальнее гцц? :)Поверьте, будет. Как человек, разрабатывающий под MIPS скажу - хуже, чем это делает gcc сделать сложно.
>Кроме того llvm значительно информативнее рапортует об ошибках.Причем тут llvm? clang - да.
лучше бы не тратили время на плагин к gcc, а работали непосредственно над clang и llvm. Разработчики gcc этого не оценят, а толку все равно немного. Лучше бы реализовали эти чертовы исключения в Windows.
итак работают
а плагин - всего-лишь замена llvm-gcc для более современных версий GCC >= 4.5.x ( llvm-gcc 4.2.1 )
Это не для разрабов гцц, а для пользователей.
>лучше бы не тратили
>а работали непосредственно
>Лучше бы реализовали эти чертовы исключения в Windows.Поддерживаю!! Начинай быстрее!!!
> Лучше бы реализовали эти чертовы исключения в Windows.Думаю что кому надо - тот и реализует.
Наконец то может быть будут сломаны старые устои. Надоел уже gcc, надеюсь llvm будет лучше и прозрачнее для меня как для разработчика.
> Наконец то может быть будут сломаны старые устои. Надоел уже gcc, надеюсь
> llvm будет лучше и прозрачнее для меня как для разработчика.Прозрачные программисты рисуют квадратики, ромбики и стрелочки, сохраняют в UML и
отдают на пожирание кодогенератору и 5 числа каждого месяца получают бабло.
Алгоритмические художники! Ёпть, Архитекторы Матриц! :)
А, так вот почему матрицу все хакали... там оказывается бредогенераторы код генерили :)
А я наоборот привык к gcc и мне лень осваивать какие-то там llvm :(
Э... А что вы с компилятором делаете, что его надо "осваивать"?
> А я наоборот привык к gcc и мне лень осваивать какие-то там
> llvm :(К чему там привыкать, тем более что clang/clang++ - drop-in замена gcc/g++? Ошибки показывает гораздо нагляднее, код генерирует более эффективный, больше, собственно, ничего не нужно.
> ... код генерирует более эффективный ...Пруфлинк?
> до достаточно высокого уровня доведена работоспособность DragonEgg для языков
> Си и Си++ <...> много работы предстоит проделать для поддержки Java.А что надо для поддержки Java? надо чтоб VM-kit стал нормальным, или что?
Вроде фронтэнд gcc (gcj) парзит Jav'у нормально, но что там с бэкэндом?