После года разработки увидел свет (http://gcc.gnu.org/gcc-4.8/) релиз свободного набора компиляторов GCC 4.8 (http://gcc.gnu.org/). Новый выпуск примечателен переходом проекта на использование языка C++, улучшением поддержки стандартов C++11 и C11, интеграцией компонентов Address Sanitizer и Thread Sanitizer, поддержкой архитектуры AArch64 (ARM64).Основные изменения (http://gcc.gnu.org/gcc-4.8/changes.html):
- Кодовая база компилятора переведена на использование языка C++. Основной код по прежнему остаётся на языке Си, но для сборки обязательно требуется компилятор С++, так как некоторые части были переписаны на C++ и теперь допускается включение в GCC новых компонентов на языке C++;
- Поддержка 64-разрядной архитектуры AArch64(ARM64), присутствующей в процессорах с набором команд ARMv8. Архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON, такими как инструкции для ускорения работы алгоритмов шифрования AES и SHA-1/SHA-256. В настоящее время устройства на базе ARMv8 пока находятся на стадии тестирования прототипов и ещё не поступили в продажу;
- Поддержка процессоров семейства Intel Haswell, AMD Jaguar и AMD Steamroller;- Интеграция компонента Address Sanitizer (http://code.google.com/p/address-sanitizer/), созданного компанией Google и прекрасно зарекомендовавшего себя при выявлении уязвимостей в браузере Chrome. Address Sanitizer позволяет выявлять ошибки в работе с памятью и факты некорректного обращения к памяти, такие как обращение к областям памяти, после их освобождения ("use-after-free"), разрушение кучи, повреждение стека, переполнение буферов. Проверки Address Sanitizer включаются через опцию "-fsanitize=address" и могут замедлить работу программы примерно в два раза за счёт добавления дополнительных проверок. Address Sanitizer может быть использован на платформах GNU/Linux (IA-32, x86-64, x32, PowerPC, PowerPC64) и Darwin (x86-64);
- Добавлен режим Thread Sanitizer (http://code.google.com/p/data-race-test/wiki/ThreadSanitizer) (-fsanitize=thread), предназначенный для обнаружения эффекта "гонки" при совместном доступе к одним и тем же данным из различных нитей многопоточного приложения. Thread Sanitizer базируется на коде из программы Valgrind. Использование Thread Sanitizer может до 10 раз замедлить работу программы. Режим доступен только для платформы x86-64 GNU/Linux;
- Новый уровень оптимизации "-Og", позволяющий повысить удобство отладки за счёт существенного сокращения времени компиляции. В режиме "-Og" компилятор производит только минимальные оптимизации, не влияющие на результаты при отладке;
- Улучшения в поддержке стандартов C++11 и C11, а также реализация ряда возможностей будущего стандарта C++1y;
Дополнительно можно отметить интересное исследование (http://rusty.ozlabs.org/?p=330) производительности работы кода, собранного компиляторами Си и Cи++ из состава GCC 4.7.2. В итоге опровергнуто мнение, что код на языке Си собранный компилятором сс медленнее, чем если данный код будет собран компилятором с++. Подмножество языка Си, доступное при сборке компилятором С++, по эффективности не уступает чистому компилятору Си, разница составляет всего 0.1%. Таким образом переход GCC на сборку компилятором С++ не скажется на производительности.
URL: http://gcc.gnu.org/gcc-4.8/
Новость: http://www.opennet.ru/opennews/art.shtml?num=36467
> могут замедлить работу программы примерно в два раза за счёт добавления дополнительных проверокДа хоть в десять, здесь можно и потерпеть.
Смотря где. Если этим пользоваться постоянно в рантайм а не только для дебага - в 10 раз хреново. Да и в 2 тоже не сильно хорошо.
Клево-клево. У них там для C++11 всего две фичи осталось доделать: Rvalue references for *this и Minimal support for garbage collection and reachability-based leak detection.
а разве многопоточные фичи уже все реализованы?
угу.
>В итоге опровергнуто мнение, что код на языке Си собранный компилятором сс медленнее, чем если данный код будет собран компилятором с++.издеваются что ли?
как шланг вс гцц, так при споре кто круче, то меряются почему-то скоростью компиляции. как гцц4.7 вс гцц4.8, то чей результирующий код быстрее.
идиотизм.
да хоть на жабе компилятор пишите, а результирующий код будет зависеть от применённых алгоритмов, а не от языка. при этом скорость компиляции будет на порядок отличаться.
Код там пока остался фактически тем же, бакэнд тоже. Просто раньше использовали сишный фронтенд для компиляции, сейчас - плюсовый. И на скорость работы собранного это не повлияло, что логично.
да ерунда это всё на самом деле.
а вот что не ерунда, так это возможные косяки при сборке мира, которые порой при минорных релизах случались, а тут и версия, и фичи, и компилятор.
Ну, это дело такое - выловят, пофиксят. Как не раз было уже. Зато, может, побыстрее развиваться станет, а то шлангам всяким эппловским отдавать первенство было бы грустно.
> а то шлангам всяким эппловским отдавать первенство было бы грустно.а какая разница? я лично присяги на верность не подписывал. будет шланг лучше и будет поддерживать всё, что мне надо — пойду на шланг. станет хуже — вернусь на гцц. нужно будет — буду оба применять.
> оба применять.Очевидным недостатком является нужда впихать в мозг в 2 раза больше знаний с малоочевидным профитом. А как известно, знаний в мире накоплено намного больше чем может уместить один человеческий мозг.
достаточно один стандарт. на то он — сюрпрайз — и стандарт.
> достаточно один стандарт.Ну покажи мне стандарт на, допустим, линкерные скрипты, если такой умный...
>> достаточно один стандарт.
> Ну покажи мне стандарт на, допустим, линкерные скрипты, если такой умный…знаешь, когда я в последний раз писал линкерный скрипт? ТА-ДАААМ! никогда!
> знаешь, когда я в последний раз писал линкерный скрипт? ТА-ДАААМ! никогда!Ну это уж кому что. Таки мне нравится раскладывать байтики предсказуемо. В эмбедовке довольно актуально. А там еще всякие специфичные для компилера опции и прочая, etc.
ну так и сиди себе на гцц. всё равно кланг пока что на этом поле не игрок.
> ну так и сиди себе на гцц. всё равно кланг пока что на этом поле не игрок.Дык так и делаю. Спасибо, Капитан. Ты все-таки не потерял квалификацию :)
p.s. а опции мне билд-система разрулит. её один раз научил — и всё.
> p.s. а опции мне билд-система разрулит. её один раз научил — и всё.А так придется два раза. //да, я ленивый бастард...
>> p.s. а опции мне билд-система разрулит. её один раз научил — и всё.
> А так придется два раза. //да, я ленивый бастард...всё равно один. потому что один она уже умеет. так-то!
впрочем, одну из самых важных шлангофич уже сделали, не боись, мужики: теперь по умолчанию место ошибки подчёркивается крышками! я джва года ждал и мечтал о том, чтобы при сборке у меня в терминал как можно меньше сообщений об ошибках помещалось. и чтобы я был вынужден проверять версию gcc в скриптах сборки, потому что старые версии, натурально, параметр «убери в задницу свои крышки» не понимают.отличное нововведение, ящитаю, очень нужное и удобное. и для тех, кто пользуется редакторами, позволяющими автоматически прыгать на строку и позицию с ошибкой, нужное: как же они без крышек?! и тем, кто не пользуется: ведь чем больше приходится листать историю терминала, тем менее скучно жить на свете.
с нетерпением жду, когда же вывод компилятора ещё и покрасят в разные цвета. а то немодно уже без попугаистости.
> с нетерпением жду, когда же вывод компилятора ещё и покрасят в разные
> цвета. а то немодно уже без попугаистости.Попугаистость попугаистостью, а gcc 2.x/3.x вываливали ошибки так, что хотелось просто прибить тех кто это придумал. В общем конкуренция таки никому еще не вредила.
А при нормальном процессе сборки билд валится от 1 ошибки - какая разница сколько там влезает, 5 ошибок или 10, если он стопнется на первой же? Это раньше gcc продолжал фигачить еще полминуты, обильно вываливая ошибки вытекающие из предыдущей :)
благодарю, я сам решу, что для меня «нормальный процесс сборки». и для меня — есть разница. для кого нет — может хоть баннеры во весь экран вместо ошибок иметь, я не запрещаю. но делать идиотизм с подчёркиванием opt-out — это идиотизм в квадрате. внизапна! именно потому, что если ты пользуешься редактором — то редактор распарзит выхлоп и направит. а если нет — есть огромный шанс, что хочешь посмотреть кучу ворнингов сразу, и побольше.если бы фичу сделали opt-in, я бы не возмущался вообще: все старые скрипты сборки работают как надо, все инструменты тоже. однако же нет: фича opt-out. и теперь в скрипты добавляется ещё и идиотия с проверкой версии гцц (ведь старая версия не знает параметра «отключить крышки» и валится сразу, как только его увидит — очень умно).
> посмотреть кучу ворнингов сразу, и побольше.Никогда не понимал тех кто хочет сперва навалить кучу компоста а потом ее полдня раскапывать. Это конечно твое дело как организовывать твой процес, но как ты понимаешь, на лично тебя одного никто не ориентируется.
> если бы фичу сделали opt-in, я бы не возмущался вообще:
А почему ее надо делать opt-in? Есть уверенность что большинству програмеров юзающих этот компилер так удобнее было бы? Для меня вот например ситуация когда надо разгрести 20 ошибок или варнингов за раз является чем-то из ряда вон. А то что лично ты не есть центр вселенной и пуп земли - наверное пора бы уже привыкнуть за столько лет.
> проверкой версии гцц (ведь старая версия не знает параметра «отключить крышки»
> и валится сразу, как только его увидит — очень умно).Ну это конечно да, однако большинству скриптов будет вообще до балды на эти опции, имхо. И таки да, если компил сломался - намного лучше если мне покажут вербозное инфо о факапе чем я буду с киркой и зубилом сам его добывать где-то сбоку. Почем зря возня на ровном месте.
> Никогда не понимал тех кто хочет сперва навалить кучу компоста а потом
> ее полдня раскапывать.я тебе секрет открою: именно варнинги — их удобней скопом убирать. потому что это обычно опечатки или около того.
>> если бы фичу сделали opt-in, я бы не возмущался вообще:
> А почему ее надо делать opt-in?а потому, что вывод компилятора не ломается. нужна тебе фича — поставил в билд-системе флаг, и всё.
могут сказать: «ну, не нужна — поставил, и всё.» всё, да не всё: если я попиливаю чужой проект, я заколебусь билд-систему править после каждого git-pull, да защищать от git-push. а если у автора не 4.8? опа-па, у него вообще такой опции нет. ок, пусть даже opt-in, но если бы 4.7 и ниже не падали (не отказывались работать) от незнакомой опции…
> Есть уверенность что большинству програмеров юзающих
> этот компилер так удобнее было бы?есть уверенность, что новые *косметические* фичи надо делать opt-in. особенно intrusive фичи. хотя бы на ту версию, в которой они введены. если, положим, через год выйдет 4.9 — ок, там можно и opt-out, к тому времени кто не перешёл на 4.8, который нужную опцию понимает — сам себе полено.
> Ну это конечно да, однако большинству скриптов будет вообще до балды на
> эти опции, имхо. И таки да, если компил сломался — намного
> лучше если мне покажут вербозное инфо о факапе чем я буду
> с киркой и зубилом сам его добывать где-то сбоку. Почем зря
> возня на ровном месте.зачем тебе это «инфо», если ты всё равно получишь его в редакторе, когда полезешь править? причём с намного более широким контекстом. а если не полезешь — то тебе и вовсе эта информация не нужна.
> я тебе секрет открою: именно варнинги — их удобней скопом убирать. потому
> что это обычно опечатки или около того.Не заметил особого удобства в совании в совершенно разные закоулки по методу лоскутного одеяла.
> а потому, что вывод компилятора не ломается. нужна тебе фича — поставил
> в билд-системе флаг, и всё.IMHO, то что удобно большинству юзеров (прикольно звучит относительно компилера) должно быть дефолтами а не опцией. Муд@хоаться с недефолтными опциями - таки удел избранных. Ну, как мне с линкерными скриптами примерно. Я ж не вякаю что это довольно брейнфакерно и все такое. Хоть оно и.
> каждого git-pull, да защищать от git-push. а если у автора не 4.8?
А что, ввинтить желаемое куда-нибудь в cflags/cxxflags или какой-нить альяс на компилер - не вариант? Обычно когда кому-то хочется довольно жестко оверрайднуть какую-то настройку компилера или впихнуть какие-то ключ(и) от себя с минимальными усилиями - делают как-то так. Билд систему патчить при этом разумеется не надо (а нафига?). Хотя конечно можно и в самом компилере выпилить, но это как-то уж совсем кардинальное решение :)
> работать) от незнакомой опции…
Ну да, с этим кому-то может быть неудобно, согласен. Поэтому при такой реализации логичнее скармливать опцию на машине с gcc 4.8. Доп. возня? Ну да, могу понять причины неудовольствия. Но подозреваю что найдется и много тех кому свистелка наоборот понравится.
> есть уверенность, что новые *косметические* фичи надо делать opt-in.
Ну если ты лучше всех знаешь как надо делать компилеры - так надери этим гадам задницы, сделав свой компилер, в два раза лучше чем у них.
> к тому времени кто не перешёл на 4.8, который нужную опцию понимает — сам себе полено.
На самом деле таких поленьев довольно много, например на всякую эмбеддовку портируют с довольно большим опозданием иногда. Хотя в последнее время некромансия сходит на нет более-менее. Очень уж это неудобно. Но местами некроманы таки встречаются.
> зачем тебе это «инфо», если ты всё равно получишь его в редакторе,
В лучшем случае позволит быстрее выхватить проблемное место глазами. Хотя...
> когда полезешь править? причём с намного более широким контекстом. а если
> не полезешь — то тебе и вовсе эта информация не нужна....хотя честно говоря по-моему эта мелкая буита не стоит такого внимания к ней. Но если реально задело - ну в мыллист отругайся, что мол так и так - неудобства создало. Может на будущее учтут, etc. Я не думаю что gcc пишут свирепые акулы, ставящие самоцелью кому-то специально нагадить.
>> я тебе секрет открою: именно варнинги — их удобней скопом убирать. потому
>> что это обычно опечатки или около того.
> Не заметил особого удобства в совании в совершенно разные закоулки по методу
> лоскутного одеяла.у тебя редактор не умеет по строкам прыгать, что ли? у меня — умеет. как я уже сказал, большинство ворнингов — тупо опечатки, которые правятся в режиме brain-off, именно скопом. да, грешен, делаю опечатки.
> Муд@хоаться с недефолтными опциями — таки удел избранных.
а делать intrusive changes как opt-out, не дав времени подготовиться — стратегия идиотов, я считаю. я уже писал: в 4.9 — пусть. но сразу-то зачем?
> А что, ввинтить желаемое куда-нибудь в cflags/cxxflags или какой-нить альяс на компилер
> — не вариант?нет, не вариант. флаги в большинстве случаев (и в автокрапе тоже, да) можно перекрыть, а вот дополнить — фигушки. потому что авторы этих систем не хотят писать свои парзеры флагов, чтобы передать компилеру нечто разумное в итоге. да и авторы скриптов сборки достаточно часто делают так: «есть внешние? используем их. нет? ставим свои.» поэтому не вариант, увы. bwah, у меня в некотором софте тоже кое-где особые флаги нужны, и это, в принципе, не единичный случай.
> Хотя конечно можно и в самом компилере выпилить,
> но это как-то уж совсем кардинальное решение :)не выпилить, а сменить умолчание. для опции, единственный результат которой — куча мусора на экране. фтопку.
> Ну да, с этим кому-то может быть неудобно, согласен. Поэтому при такой
> реализации логичнее скармливать опцию на машине с gcc 4.8. Доп. возня?
> Ну да, могу понять причины неудовольствия. Но подозреваю что найдется и
> много тех кому свистелка наоборот понравится.понравится — добавят во флаги, как ты сам выше и предлагал. ещё раз: проверять на идиотский gcc 4.8 будет *везде*, а добавлять опцию человек будет точно зная, что у него 4.8, и эта опция работает. лично я считаю второй подход разумней. а в 4.9 они станут задом наперёд всё выводить, потому что так прикольно — и на 4.9 проверяй. ты знаешь, примерно вот так появился автокрап.
>> есть уверенность, что новые *косметические* фичи надо делать opt-in.
> Ну если ты лучше всех знаешь как надо делать компилеры — так
> надери этим гадам задницы, сделав свой компилер, в два раза лучше
> чем у них.я лучше них знаю, как добавлять intrusive features, да. как оказалось. впрочем, они от меня писем не берут в свои листы, у них там какой-то идиотический блэклистер, считающий меня спамером. мне, в принципе, пофигу, почему: я у себя и пропатчить исходник могу. а кому не понравится — тот может уже писать жалобу в оон, править мой софт, не использовать мой софт — вариантов масса.
>> к тому времени кто не перешёл на 4.8, который нужную опцию понимает — сам себе полено.
> На самом деле таких поленьев довольно много, например на всякую эмбеддовку портируют
> с довольно большим опозданием иногда.вот это точно не волнует. во-первых, эмбеддерам не привыкать к акробатике, а во-вторых, мой софт там однозначно не нужен. :3
> Но если реально задело — ну в мыллист отругайся
см. выше.
> Я не думаю что gcc пишут свирепые акулы, ставящие самоцелью
> кому-то специально нагадить.но мозг они иногда включать таки забывают. не то, чтобы фатально, однако же неприятно.
p.s. кстати, что забавно: настоящие спамеры в листы вполне себе пролазят.
и, кстати, ещё: я не смотрел исходник гцц, но: или они должны хранить кучу доплнительной инфы, чтобы выдать мне строку точно в том виде, в каком она в файле была, или их pretty-printer отформатирует её по своему. в первом варианте — бессмысленный расход памяти, а во втором вообще ужас.да второй и не реализуем толком, так что только первый. итого, фича помимо мусора на экране влечёт за собой ещё и мусор в RAM. офигеть улучшили.
там же временные файлы есть, которые по умолчанию удаляются, там и хранятся эти строки, как они были, вперемешку с мнемониками асма.
или речь о другом?
> там же временные файлы есть, которые по умолчанию удаляются, там и хранятся
> эти строки, как они были, вперемешку с мнемониками асма.
> или речь о другом?ну, пусть во временных файлах — я ж говорю, не смотрел, где хранят. «суть-то в том», (ц) что это тупо не нужно всё, лишняя трата ресурсов. для индикации (строка,позиция) достаточно рядом с токеном хранить именно эти два значения (ну, ещё имя исходного файла в отдельном словаре). всё остальное — это лишний код и лишние ресурсы. кому очень-очень хочется крышек — тот может написать себе скрипт, который будет хватать вывод gcc и дорисовывать крышки. на кой это в компиляторе — вообще не ясно.
я, впрочем, поступил не менее нагло: просто выключил её и пересобрал gcc. если у кого-то с gcc 4.8 некоторые мои скрипты сборки упадут — я любезно предоставлю им адрес списка рассылки gcc, где они могут высказать все впечатления о крышках. подстраиваться под идиотизм в квадрате я не буду.
> могут высказать все впечатления о крышках. подстраиваться под идиотизм в квадрате я не буду.Ну так и не подстраивайся, ты так говоришь как будто к тебе мужика с автоматом прислали, надзирать что ты крышки юзаешь. И да, ты уверен что если к фиче народ привыкнет а ее потом выпилить то opt-in вызовет у ALL меньше неудовольствия чем opt-out? Я конечно понимаю что тебя проблемы остальных не волнуют. Но то же самое могут сказать и окружающие о твоих проблемах, не так ли?
> Ну так и не подстраивайся, ты так говоришь как будто к тебе
> мужика с автоматом прислали, надзирать что ты крышки юзаешь.к сожалению, дистрибутивы идиотизм в квадрате выпиливать не будут. поэтому можно сказать, что приставили.
> ты уверен что если к фиче народ привыкнет а ее потом
> выпилить то opt-in вызовет у ALL меньше неудовольствия чем opt-out?я не предлагаю «потом», я предлагаю прямо сейчас сделать её отключеной по-умолчанию.
> к сожалению, дистрибутивы идиотизм в квадрате выпиливать не будут. поэтому можно
> сказать, что приставили.Ну знаешь, а вот мне дистр не собрал компилер под пяток не очень часто встречающихся архитектур. Только на самые распостраненные. Получается что у меня вообще целая рота расквартировалась? :). ИМХО не совсем гуманно заставлять майнтайнеров билдить все это - возможно сильно уж дофига вариантом сборки.
> я не предлагаю «потом», я предлагаю прямо сейчас сделать её отключеной по-умолчанию.
После релиза клавиатурой не машут. Так что это "потом" можно считать что уже здесь.
> После релиза клавиатурой не машут. Так что это "потом" можно считать что
> уже здесь.so be it. мне, в принципе, несложно патч к скриптам сборки докинуть (что я и сделал). ну, не в первый раз приходится править идиотизм авторов всякого софта таким образом.
> с нетерпением жду, когда же вывод компилятора ещё и покрасят в разные
> цвета. а то немодно уже без попугаистости.у меня для тебя плохие новости...
> у меня для тебя плохие новости...я в курсе про шланг. на него и намекал.
>да хоть на жабе компилятор пишите, а результирующий код будет зависеть от применённых алгоритмов, а не от языка.это верно в теоретически-сферически-вакуумном случае. на практике начинаются приколы ввиде пробоев кеша, невыровненных запросов к памяти и прочие забавные вещи
> Таким образом переход GCC на сборку компилятором С++ не скажется на производительности.Враки. Не сказывается это только на канонiчном тесте на синтетике. В реальной программе, особенно написаной индусом, без внятного понимания как работают библиотеки которыми он пользуется, где тривиальный виртуальный метод наследуется по четыре сотни раз в принципе весь OOP выглядит как байтораздирающее зрелище.
Реверсил, плавал...
GCC пишут отнюдь не индусы без внятного понимания. А речь именно о сборке GCC плюсами.Ну и да, дурак что угодно угробит.
>Дополнительно можно отметить интересное исследование производительности работы кодане интересное там исследование, т.к. нет картинок :-)
Интересно что там заготовлено на 3.9, какие вкусности. Пока заметил в транке патчи связанные с векторами, так и не понял зачем они.
> Интересно что там заготовлено на 3.9зачем три-девять? не надо три-девять.
> зачем три-девять? не надо три-девять.Надо. Уже rc3 есть. Правда вот это ядро линукса. Оно хорошее, честно-честно. Там ряд тупых багов исправлен :).
блин, только вчера RC собрал. не могли месяцок потерпеть.
он, небось, только номером и отличается, если вчера собирал.
> он, небось, только номером и отличается, если вчера собирал.всё равно неприятно, когда --version рапортует об RC. пусть рапортует нормально. и потом: машина железная, за час на фоне спокойно пересобрала, пока я кино смотрел.
Вопрос к посвящённым. Что дало переписывание кода GCC с Си на Си++? Какую цель преследует эта работа?
> Вопрос к посвящённым. Что дало переписывание кода GCC с Си на Си++?
> Какую цель преследует эта работа?упрощение maintenance. и вообще, на странице gcc указаны причины, даже сильно искать не надо.
RMS проиграл многолетнюю битву с любителями множественного наследования темплейтов фактори лямбда функций. Те, пока чтобы не спугнуть, пока переписали самую малость, чисто для пробы. Но обфуcкация уже запущена, мало помалу GCC превратится как и остальные С++ проекты, в нечитаемую жуть.
>для сборки обязательно требуется компилятор С++, так как некоторые части были переписаны на C++да уж, инновация..
Не нужно.
Только clang, только llvm.
Звучит как: только хардкор только тормоза.
Так когда там к clang прикрутят openmp? ну и заодно исправят проблемы с математикой, что некоторый софт как то вектора выдает примерно на порядок длинее чем надо (точнее чем правильно и работает на других компиляторах gcc-4.6+ intel-12+ xlc)
> Только clang, только llvm.Это который ничего кроме х86 и (в зачаточном состоянии) некоторых подвидов ARM толком не поддерживает? Да и на тех оптимальность кодогенерации - паршивая? Не, спасибо, некоторых волнует не "%s - круто!!!" а фактический результат.
>> Только clang, только llvm.
> Это который ничего кроме х86 и (в зачаточном состоянии) некоторых подвидов ARM
> толком не поддерживает? Да и на тех оптимальность кодогенерации - паршивая?
> Не, спасибо, некоторых волнует не "%s - круто!!!" а фактический результат.а кому нужнен этот набор архитектур - когда основная платформа x86? вы часто собираете под другие архитектуры?
да и кодогенератор из байтокода в реальный код - пишется чуть более чем тривиально.
Это же не gcc - который генерит сразу в asm платформы.
> а кому нyжнен этот набор архитектур -Мнe нyжен. Я регулярно собираю под ARM всех мастей и MIPS. Иногда под MSP430 и AVR. И у меня вообще х86 нет. Ну самый край x86_64, который заметно отличается.
> когда основная платформа x86?
Это у некрофaгов всяких она основная. А в мире очень нехилый такой сдвиг в сторону ARM произошел. То что вы лишний раз будете на обочине с вашими х86 грoбами - так вам и надо.
> да и кодогенератор из байтокода в реальный код - пишется чуть более чем тривиально.
Оно и видно - парни из AMD два года p@кoм стояли, пытаясь убедить этот шит сгенерить хотя-бы просто технически валидный поток команд для своего VLIW. На примере амд я уже увидел насколько это тривиально. Там же в списке рассылки некий Вадим Гирлин рассказал насколько просто оптимизировать код в LLVM относительно местечкового кодогенератора. Так что шли б вы с вашим маркетинговым булшитом!
Когда будут ебилды?
> Когда будут ебилды?Дожили, спецы по перекомпиляции мира не могут собрать себе ... компилятор. Скажите, какого гуя я могу собрать себе gcc в какой-то там хубунте, не дожидаясь пока мне кто-то поднесет на блюдечке, с голубой каемочкой, а?
дедушка шутит.
>> Когда будут ебилды?
> Дожили, спецы по перекомпиляции мира не могут собрать себе ... компилятор. Скажите,
> какого гуя я могу собрать себе gcc в какой-то там хубунте,
> не дожидаясь пока мне кто-то поднесет на блюдечке, с голубой каемочкой,
> а?Чего прицепился к виндузятнику ? :)
emerge --info
Portage 2.2.0_alpha171 (default/linux/amd64/13.0, gcc-4.8.0, glibc-2.17, 3.8.2-gentoo-4 x86_64)
=================================================================