https://www.opennet.ru/openforum/vsluhforumID3/76044.html Андрес Магнуссон (Anders Magnusson) представил (http://marc.info/?l=pcc-list&m=130167083618322&w=2) первый стабильный релиз компилятора PCC 1.0.0 (http://pcc.ludd.ltu.se/) (Portable C Compiler), развиваемого с целью создания альтернативы Си-компилятора из состава GCC, распространяемой (ftp://pcc.ludd.ltu.se/pub/pcc-releases/) под лицензией BSD. PCC достиг стабильного состояния при работе на платформах i386 и amd64 в различных ОС, включая BSD-системы, большинство Linux-дистрибутивов, а также Microsoft Windows. Поддержка остальных аппаратных платформ еще недостаточно отлажена и может содержать ошибки и недоработки. Следом за версией 1.0.0 в недалёком будущем будет выпущено несколько корректирующих релизов, после чего ожидается версия 1.1 с реализацией более серьезных изменений.<br><br>На данный момент PCC может быть использован (http://bsdfund.org/projects/pcc/) для сборки большинства составляющих базовой системы FreeBSD (http://www.opennet.ru/opennews/art.shtml?num=29433), NetBSD (http://ww...<br><br>URL: http://marc.in https://www.opennet.ru/openforum/vsluhforumID3/76044.html#93 Tue, 12 Apr 2011 07:25:05 GMT &gt; И второй случай из недавнего читалка TSC-регистра (а-ля команда RDTSC) дабы сэкономить <br>&gt; пару байт ( функция как раз кончалась на этой ассемблерной вставке) <br>&gt; эпилог функции был перенесен мною в эту самую многострадальную __asm__ volatile(), <br>&gt; с -O0 все прекрасно, даже с просто -O Segmentation Fault. Как <br>&gt; мне кажется GCC делает оптимизацию работы со стеком и мой выкрутас <br>&gt; поломал логику оптимимзатора ( хотя не должен был) и я получил <br>&gt; SegFault.<br><br>Эпилог - да, делать точно не стоило.<br>Просто описать команду и результаты.<br> https://www.opennet.ru/openforum/vsluhforumID3/76044.html#92 Tue, 12 Apr 2011 06:39:16 GMT &gt;&gt; Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто <br>&gt;&gt; не обойтись, вот и приходится изощряться.<br>&gt; в отдельную либу, её с -O0, не забыть пояснить компилятору, какие регистры <br>&gt; дохлые.<br>&gt; кстати, а можно поинтересоваться: зачем инлайн-асм? именно вот вмонтированый в сишный исходник <br>&gt; асм мне &#8212; дай демона памяти &#8212; за 10+ лет ни <br>&gt; разу не понадобился. вообще, могу вспомнить только случаи конверсии бэкбуфера в <br>&gt; разный BPP да софтварного текстуризатора &#8212; там пришлось асм делать.<br><br>Была задачка надо было с MSR-регистрами работать с юзерленда. Отдельную либу городить - муторно, а пару __asm__ volatile () втыкнуть в код функции много проблем не доставляло.<br>И второй случай из недавнего читалка TSC-регистра (а-ля команда RDTSC) дабы сэкономить пару байт ( функция как раз кончалась на этой ассемблерной вставке) эпилог функции был перенесен мною в эту самую многострадальную __asm__ volatile(), с -O0 все прекрасно, даже с просто -O Segmentation Fault. Как мне кажется G https://www.opennet.ru/openforum/vsluhforumID3/76044.html#91 Tue, 12 Apr 2011 06:31:29 GMT &gt; Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто <br>&gt; не обойтись, вот и приходится изощряться.<br><br>в отдельную либу, её с -O0, не забыть пояснить компилятору, какие регистры дохлые.<br><br>кстати, а можно поинтересоваться: зачем инлайн-асм? именно вот вмонтированый в сишный исходник асм мне &#8212; дай демона памяти &#8212; за 10+ лет ни разу не понадобился. вообще, могу вспомнить только случаи конверсии бэкбуфера в разный BPP да софтварного текстуризатора &#8212; там пришлось асм делать.<br> https://www.opennet.ru/openforum/vsluhforumID3/76044.html#90 Tue, 12 Apr 2011 05:39:40 GMT &gt;&gt; такие грабли с -O0 код работает, даем -O2 в надежде выиграть <br>&gt;&gt; пару % производительности, но при этом получаем SIGSEGV сразу же после старта).<br>&gt; а что на это говорят -Wall и valgrind?<br>&gt;&gt; Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.<br>&gt; удивительно, не так ли? а не надо их писать, если не знаешь, <br>&gt; какой код компилятор нагенерит.<br><br>Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто не обойтись, вот и приходится изощряться.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/76044.html#89 Tue, 12 Apr 2011 05:36:36 GMT &gt;[оверквотинг удален]<br>&gt; Ты тоже оптимист. Есть широко известный глюк gcc 2.9* при сборке squid <br>&gt; при -O1 или -O3, но не -O2 :) <br>&gt; Вообще отношение к оптимизациям у gcc некорректное. Во-первых, хотя info говорит, <br>&gt; что эти уровни разлагаются на кучу отдельных параметров, в коде дофига <br>&gt; прямых проверок типа if (optimize &gt; 0). Во-вторых, при -O1 уже <br>&gt; уезжают номера строк, а при -O0 может генерироваться 10 команд с <br>&gt; пинг-понгом между регистрами, запись в стек и вычитка записанного обратно, и <br>&gt; т.д.; в результате код дико неэффективен. Правильного же промежуточного уровня - <br>&gt; какие угодно оптимизации, но в пределах отрезка кода между двумя sequence <br>&gt; point - там нет.<br><br>Согласен, оптимизатор в GCC иногда настолько суров и беспощаден, что бинарь после компиляции валится в кору, особенно если со всякими -ffast-math -O3 -funroll-all-loops -falign-* перемудрить. <br> https://www.opennet.ru/openforum/vsluhforumID3/76044.html#88 Tue, 12 Apr 2011 05:31:20 GMT &gt;&gt; Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?<br>&gt; "Если вам кажется что дела идут хорошо, значит вы просто чего-то не <br>&gt; заметили" (законы Мерфи). Как-то так исторически лично я натыкался на глюки <br>&gt; после юзания -O3 у гцц. При том порой - на редкие <br>&gt; и трудноуловимые. Оно, конечно, можно - всяких флагов навинтить. Только потом <br>&gt; придется мозг ломать - чьи глюки: программы или компилятора. Заведомо стабильные <br>&gt; оптимизации идут в -O2, а то что выше - на свой <br>&gt; зад уже ;). Кстати данный тезис и бсдунов вполне касается - <br>&gt; если они думают что баги есть только в GCC - они <br>&gt; это, оптимисты-идеалисты, видимо :) <br><br>Ты тоже оптимист. Есть широко известный глюк gcc 2.9* при сборке squid при -O1 или -O3, но не -O2 :)<br><br>Вообще отношение к оптимизациям у gcc некорректное. Во-первых, хотя info говорит, что эти уровни разлагаются на кучу отдельных параметров, в коде дофига прямых проверок типа if (optimize &gt; 0). Во-вторых, при -O1 уже уезжают номера строк, а при -O0 может генериро https://www.opennet.ru/openforum/vsluhforumID3/76044.html#87 Tue, 12 Apr 2011 05:27:24 GMT &gt; Зачем сейчас ещё один компилятор С на С? Уже десять раз бы <br>&gt; обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали <br>&gt; или схеме.<br><br>1. На Javascript - точно не обогнали бы. А какая-то специфическая форма LISP у gcc внутрях, используется на всю катушку, но супер-достижений не видно. Просто почти оптимум.<br>2. Независимая простая реализация в качестве контрольной - обязательная штука в сложных системах. Как-то даже для сравнительно простой криптографии я писал 4 реализации: C/OpenSSL, C/GnuTLS, Python и Erlang. Зато в результате я смог каждому участнику дать все 4 и сказать "вот канонический набор реализаций, сдирай код сколько угодно, но твоя реализация должна давать идентичный результат". А компиляторы диагностировать обычно сложнее криптографии.<br> https://www.opennet.ru/openforum/vsluhforumID3/76044.html#86 Tue, 12 Apr 2011 05:18:51 GMT &gt; Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён.<br><br>Ну, честно говоря, это не совсем так, есть явные исключения - встроенный ассемблер, разнообразные __attribute__(). Именно поэтому основным путём сейчас рассматривается переход на clang (который старается уметь все расширения gcc), а не pcc, хотя весь userland стараются прогнать через другие компиляторы (и icc, и pcc, и TenDRA...) чтобы получить оценку проблем конкретных кусков.<br>Но это те gcc'измы, которые "неизбежное зло".<br> https://www.opennet.ru/openforum/vsluhforumID3/76044.html#84 Wed, 06 Apr 2011 21:12:39 GMT Обновился порт lang/pcc на FreeBSD: http://www.freshports.org/lang/pcc/<br>