Андрес Магнуссон (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 с реализацией более серьезных изменений.На данный момент PCC может быть использован (http://bsdfund.org/projects/pcc/) для сборки большинства составляющих базовой системы FreeBSD (https://www.opennet.ru/opennews/art.shtml?num=29433), NetBSD (http://ww...
URL: http://marc.info/?l=pcc-list&m=130167083618322&w=2
Новость: https://www.opennet.ru/opennews/art.shtml?num=30110
Хороший компилятор. гентушники одобряют?
Когда будет быстрее GCC - одобрим.
>Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе.В новости же написано.
Я имел ввиду результат на выходе.
>>Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе.
> В новости же написано.серия 4.1? не смешите мои полудохлые тапочки. они бы ещё более древний GCC взяли, чтобы получше результаты вышли.
советую прчитать changelogs на новые gcc. про межпроцедурную и межмодульную оптимизацию хотя бы. для начала. пцц хорош для сборки мелкопроектов, где производительность, в принципе, пофигу.
я не к тому, что пцц не нужен — нужен. только не надо его с гцц сравнивать: разного калибра игроки.
> Когда будет быстрее GCC - одобрим.Когда он сможет мне сгенерить код под ARM* и MIPS32 не хуже GCC, тогда и я подумаю...
>Когда он сможет мне сгенерить код под ARM* и MIPS32 не хуже GCC, тогда и я подумаю...Как это "ПОДУМАЮ"? Погоду не порть людям Юзер. А как же святая вера в ГПЛ? У PCC не правильная лицензия, тут и думать нечего. Оно недостойно праведных бубунтоводов.
На самом деле, зная бздунов я предполагаю что мне повезет, если я увижу нечто похожее на упомянутое хотя-бы к моменту выхода на пенсию :P.
Сама мысль греховна сын мой! :( Сначала ты подумаешь про компилятор демонический, а потом и греховные мысли об установке BSD появятся. А там и до проепритарщины докатишься, и сгинет душа твоя в геенне огненной.
> и до проепритарщины докатишься,Всегда подозревал что бздуны - латентные проприетарщики, а тут прямо официальное подтверждение :)
Все верно! Ты один из самых способных, среди уверовавших в светлый образ чистой и непорочной Птицы. Ты отмечен печатью пророка нашего, и можешь с помощью своего ясного и гибкого ума отличать добро от зла.Скоро наш Великий пророк расправится со злом окончательно! И будет кругом Linux и GPL! А демонический силы навсегда будут замурованы в своей цитадели зла - Berkeley. И не будет им выхода в Интернет более, из этого проклятого места!
> И будет кругом Linux и GPL!Если его величество эволюция так распорядится - значит будет так. Те кто вымер - сами виноваты. Не смогли приспособиться к новым реалиям? Пшли вон, освободите место более достойным, которые смогут. В этом плане все относительно честно и просто ;). Каждый в своем праве потрепыхаться, но останутся только наиболее эффективные.
Нет. В лучшем случае им можно собрать только около 40% что есть в портежах. Да что там говорить?
> На данный момент PCC может быть использован для сборки большинства составляющих базовой системы FreeBSD, NetBSD и OpenBSD.
> большинства составляющихТоесть он даже не может собрать всё что есть в портах тех ОС для которых он пишется.
> Нет. В лучшем случае им можно собрать только около 40% что есть
> в портежах. Да что там говорить?
>> На данный момент PCC может быть использован для сборки большинства составляющих базовой системы FreeBSD, NetBSD и OpenBSD.
>> большинства составляющих
> Тоесть он даже не может собрать всё что есть в портах тех
> ОС для которых он пишется.О портах в статье речь не идет, он не может собрать всю базовую систему, т.е. мир
> ...он *не может* собрать всю базовую систему, т.е. мир.Не пудрите мозги людям. Как раз базовую систему (мир) он собирает. Базовая система это ядро и минимальное окружение. В /usr/src кроме ядра разные утили, bind, ftpd, sshd и т. д. А в портах лежит прикладной софт к которому разработчики BSD уже никакого прямого отношения не имеют.
А что у нас есть ещё с полной поддержкой C99?
GCC до сих пор не сподобился...
А уже новый стандарт языка на носу...
Можно примеры кода C99 не понимаемого GCC?!Вот эту табличку не надо http://gcc.gnu.org/gcc-4.6/c99status.html
Код реальный, плиз.
> Можно примеры кода C99 не понимаемого GCC?!
> Вот эту табличку не надо http://gcc.gnu.org/gcc-4.6/c99status.html
> Код реальный, плиз.в кои-то веки соглашусть с павлином. то ли я деградирую, то ли павлин умнеет...
Альтернативный свободный компилятор — это, конечно, хорошо, но более серьёзных тестов, чем сделанной почти год назад оценочной прикидки на небольшой выборке из ByteBench (в нём десятка два тестов), нет?
Может, тесты и есть. Но они не собираются :-D
> Процесс компиляции осуществляется в несколько раз быстрее, чем в GCC, при приемлемом уровне кода на выходе.То есть PCC быстрее, а дальше
> Например, сборка тестового комплекта ByteBench, выполненная при помощи gcc 4.1.3 (режим оптимизации "-O2") оказалась в большинстве тестов лишь на несколько процентов быстрее сборки с использованием PCC (исключение составил тест dhry2reg, при котором PCC отстал почти в два раза и тест hanoi, при котором отставание было на уровне 30%).
То есть PCC медленнее. о_О Поясните пожалуйста где ошибка? Или PCC медленнее только с этим пакетом?
быстрее при сборке, код немного медленнее на выходе
Здесь работает простой принцип: чем дольше запрягаешь - тем быстрее едешь
уже есть clang. этот по сравнению с clang - совсем не серьезно, и не понятно когда будет готов
Больше компиляторов, хороших и разных!
Один продукт в одной нише - отсутствие конкуренции - застой. Ну уж нет.
>отсутствие конкуренцииеё и так не будет. PCC не конкурент никак.
Типичная позиция красноглазика не понимающего зачем пишут программы сложнее hello world.
> Типичная позиция красноглазика не понимающего зачем пишут программы сложнее hello world.Это ты красноглазик, не понимающий, в чем ценность маленьких
и хорошо спроектированных программ, которые хорошо выполняют
свою функцию. Именно такими программами
и создавалась история UNIX.Знаешь, есть такая штука -- отношение
ценность/затраченные_усилия_по_написанию_и_поддержке_кода.
Так вот у pcc этот показатель очень высок.
>разрабатывается с 70-ых годов прошлого века.http://pcc.ludd.ltu.se/pcc_history/
It was publicly announced to the NetBSD community on September 14, 2007. Shortly later it was imported to the OpenBSD, NetBSD, and pkgsrc source trees.
Most stuff is written by Anders Magnusson
>выполненная при помощи gcc 4.1.3а с 2.95 сравнить не хотят? на дворе 2011 год, 4.6.0 вышел.
В целом оно не нужно, есть clang(llvm)
так ведь бсдшники всегда с 1913 годом сравнивают
Как сказать, в той же FreeBSD вероятно теперь gcc отправят в систему портов из базовой системы, как это когда-то произошло с Perl. Базовая система быстрее будет собираться благодаря этому. А исходный код BSD-систем скорее всего начнут оптимизировать под pcc. Так что для BSD-систем плюсы есть, для остальных они пока сомнительны.
Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать под "ещё один компилятор" никто не будет.
> Коммит gcc'измов запрещён.Не знал. Но в любом случае, на компиляцию самого gcc уходит слишком много времени при сборке системы. И если мне не изменяет память gcc два раза при этом процессе собирается.
три
> Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать
> под "ещё один компилятор" никто не будет.Как обычно, в теории все круто а на практике - ну вы в курсе, да? Система без софта под нее - и даром никому не нужна. Осталось только убедить авторов прикладух не юзать gcc'измы, и дело в шляпе :)
>> Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать
>> под "ещё один компилятор" никто не будет.
> Как обычно, в теории все круто а на практике - ну вы
> в курсе, да? Система без софта под нее - и даром
> никому не нужна. Осталось только убедить авторов прикладух не юзать gcc'измы,
> и дело в шляпе :)Прикинь: FreeBSD полноценно работает без ПО, собранного GCC из коллекции портов (тупо каталог /usr/local пуст). При этом может работать роутером (IPF, PF, IPFW) и файлсервером (NFS, FTP), работает SSH, пользовательская консоль (sh, tcsh).
Заметь: GCC для поднятия этого УЖЕ не нужен!
> каталог /usr/local пуст). При этом может работать роутером (IPF, PF, IPFW)Ололо :) у меня роутер работал даже когда libc убился. Кернелу на это libc и прикладной крап вообще плевать :) оно там живет своей жизнью, пакетики гоняет. Правда, боюсь что мало кто разделит такой оптимизм.
> и файлсервером (NFS, FTP), работает SSH, пользовательская консоль (sh, tcsh).Ну прямо достижения дедов и прадедов повторили. Круто, круто! :)))
> Заметь: GCC для поднятия этого УЖЕ не нужен!
Да вообще, хана этому праааааативному гцц, однозначно :).
> Прикинь: FreeBSD полноценно работает без ПО, собранного GCC из коллекции портов (тупо
> каталог /usr/local пуст). При этом может работать роутером (IPF, PF, IPFW)
> и файлсервером (NFS, FTP), работает SSH, пользовательская консоль (sh, tcsh).
> Заметь: GCC для поднятия этого УЖЕ не нужен!то есть, делает то, что умеет коробочка за три копейки, пылящася у меня в углу? круто, нечего сказать. а что-то, чего коробочка не умеет, можно? ну, там, 3д повертеть с парой сотен тыщ полигонов в рилтайме, например?
>> Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён. Оптимизировать
>> под "ещё один компилятор" никто не будет.
> Как обычно, в теории все круто а на практике - ну вы
> в курсе, да? Система без софта под нее - и даром
> никому не нужна. Осталось только убедить авторов прикладух не юзать gcc'измы,
> и дело в шляпе :)Авторы "пликладух" среагируют только тогда, когда разные компиляторы,
на горизонте появятся. И они появляются, clang и pcc, так что процесс УЖЕ идет.
Задача номер два -- пакетировщикам софта в дистрибутивах не
держать патчи у себя, а пинать апстрим as soon as possible.
> Авторы «пликладух» среагируют только тогда, когда разные компиляторы,
> на горизонте появятся.и при этом если они будут поддерживать расширения gcc. иначе — «пишите патчи, господа». я, например, вовсю «gcc'измами» пользуюсь, и отказываться от них (а там есть вкусного, да) только из-за того, что на других компилерах не собирается… неа. пусть другие компилеры допиливают поддержку gcc, это de-facto стандарт.
> Исходный код FreeBSD написан на ISO-стандартном языке. Коммит gcc'измов запрещён.Ну, честно говоря, это не совсем так, есть явные исключения - встроенный ассемблер, разнообразные __attribute__(). Именно поэтому основным путём сейчас рассматривается переход на clang (который старается уметь все расширения gcc), а не pcc, хотя весь userland стараются прогнать через другие компиляторы (и icc, и pcc, и TenDRA...) чтобы получить оценку проблем конкретных кусков.
Но это те gcc'измы, которые "неизбежное зло".
> так ведь бсдшники всегда с 1913 годом сравниваютблагодаря этому и сегодня опыт полученный 20 лет назад полезен пользователям BSD. ну разве, что новые команды появляются.
Чего не скажешь о Apple и Microosft где каждый год новая идиотская идея убить все что было раньше и переписать по новой. в свое время я изучаю Quick Basic и писал на нем лабы, а спустя пару лет дети пишут лабы на Visual Basic, а сегодня Visual Basic .NET, а ведь для базового понимания алгоритмов эти все обвесы не нужны.
P.S. Мой поклон и уважение BSD-шникам. Ценим и любим!
При чём здесь эппл и быдло.нет? То, что бсдшники написали ещё один компилятор - это, безусловно, плюс. Но лицензионные проблемы - это их проблемы, они не должны сказываться на объективном сравнении компиляторов. Нужно сравнивать современные версии: 4.6 и 1.0, или 4.1.3 и что_там_было_у_pcc. Иначе 1913 год.
И много дистрибутивов используют версию 4.6?
Вы не с того конца зашли, даже в Debian oldstable входит GCC 4.3.2, а так кругом GCC 4.4.5 или около того... то что GCC 4.6 ещё не внедрили даже в testing-дистрибутивы вина его молодости, и это никак не связано с проблемами BSD-шников с их отношением к GPL3.
http://www.archlinux.org/packages/?sort=-last_update&q=gcc&m...
Больше компилеров, хороших и разных. Линус кстати в последнее время очень ругал GCC за оптимизацию кода, которая в некоторых случаях ломает бинарники и те вываливаются в Segmentation Fault ( сам пару раз вставал на такие грабли с -O0 код работает, даем -O2 в надежде выиграть пару % производительности, но при этом получаем SIGSEGV сразу же после старта). Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.
> сам пару раз вставал на такие грабли с -O0 код работает, даем -O2 в надежде выиграть пару % производительности, но при этом получаем SIGSEGV сразу же после стартаИнтересно, результаты компиляции PCC сравнивают с результатом компиляции под какой опцией GCC, с "-O0" или "-O2"?
>сборка тестового комплекта ByteBench, выполненная при помощи gcc 4.1.3 (режим оптимизации "-O2")
>>выполненная при помощи gcc 4.1.3А чего не с 2.95 то? А то уже 4.6 вышел... если уж хочется показать забористость результатов, сравнение с 2.95 будет еще эпичнее чем с 4.1.3...
потомучто 4.1.3 это последняя версия которая устраивает бздунов по лицензии
> потомучто 4.1.3 это последняя версия которая устраивает бздунов по лицензиипрежде чем писать х.ню ознакомьтесь с вопросом. пожалуйста.
Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?
> Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?Я уже писал выше - что все очень специфично к коду, который написан. У меня в генте например не хотел glib с высокими оптимизациями работать, на некоторые пакеты emerge выводил предупреждение, что он убирает -Ox и -march=/-mtune= из CFLAGS ввиду того что пакеты с этими опциями сборки некорректно работают.
Ядро и с -O6 неплохо собирается, вот только толку особого от этого нет=)
вот это:
>-march=/-mtune=брехня. полная при чём.
едиственное на что матюги видел - этого на оптимизацию с графитом.
что в общем и логично.
а матюги на архитектуру - это точно брехня.
> вот это:
>>-march=/-mtune=
> брехня. полная при чём.
> едиственное на что матюги видел - этого на оптимизацию с графитом.
> что в общем и логично.
> а матюги на архитектуру - это точно брехня.glib (не glibc)с -mtune=generic -O0 собирается и hald/dbus работают без граблей, с -mtune=core2 -O3 собирается но не работают ( SegFault) hald и dbus.
Не знаю, может звезды были не в положении для emerge, но не работало - хоть убей.
> Не знаю, может звезды были не в положении для emerge, но не
> работало - хоть убей.потому что -O3 включает в себя некоторые "опасные" оптимизации. о чём написано в документации gcc, но чукчи же не читатели.
> Ядро и с -O6 неплохо собирается, вот только толку особого от этого
> нет=)конечно, нет, потому что цифра больше 3 в -O значит ровно то же самое, что и тройка. хоть -O9. за пруфами — welcome в исходники или список рассылки gcc, где этот вопрос с завидной пероидичностью задают.
> Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?"Если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили" (законы Мерфи). Как-то так исторически лично я натыкался на глюки после юзания -O3 у гцц. При том порой - на редкие и трудноуловимые. Оно, конечно, можно - всяких флагов навинтить. Только потом придется мозг ломать - чьи глюки: программы или компилятора. Заведомо стабильные оптимизации идут в -O2, а то что выше - на свой зад уже ;). Кстати данный тезис и бсдунов вполне касается - если они думают что баги есть только в GCC - они это, оптимисты-идеалисты, видимо :)
>> Поставил убунту на самособраное ядро с -O3. Как видишь вся ок. ЧАДНТ?
> "Если вам кажется что дела идут хорошо, значит вы просто чего-то не
> заметили" (законы Мерфи). Как-то так исторически лично я натыкался на глюки
> после юзания -O3 у гцц. При том порой - на редкие
> и трудноуловимые. Оно, конечно, можно - всяких флагов навинтить. Только потом
> придется мозг ломать - чьи глюки: программы или компилятора. Заведомо стабильные
> оптимизации идут в -O2, а то что выше - на свой
> зад уже ;). Кстати данный тезис и бсдунов вполне касается -
> если они думают что баги есть только в GCC - они
> это, оптимисты-идеалисты, видимо :)Ты тоже оптимист. Есть широко известный глюк gcc 2.9* при сборке squid при -O1 или -O3, но не -O2 :)
Вообще отношение к оптимизациям у gcc некорректное. Во-первых, хотя info говорит, что эти уровни разлагаются на кучу отдельных параметров, в коде дофига прямых проверок типа if (optimize > 0). Во-вторых, при -O1 уже уезжают номера строк, а при -O0 может генерироваться 10 команд с пинг-понгом между регистрами, запись в стек и вычитка записанного обратно, и т.д.; в результате код дико неэффективен. Правильного же промежуточного уровня - какие угодно оптимизации, но в пределах отрезка кода между двумя sequence point - там нет.
>[оверквотинг удален]
> Ты тоже оптимист. Есть широко известный глюк gcc 2.9* при сборке squid
> при -O1 или -O3, но не -O2 :)
> Вообще отношение к оптимизациям у gcc некорректное. Во-первых, хотя info говорит,
> что эти уровни разлагаются на кучу отдельных параметров, в коде дофига
> прямых проверок типа if (optimize > 0). Во-вторых, при -O1 уже
> уезжают номера строк, а при -O0 может генерироваться 10 команд с
> пинг-понгом между регистрами, запись в стек и вычитка записанного обратно, и
> т.д.; в результате код дико неэффективен. Правильного же промежуточного уровня -
> какие угодно оптимизации, но в пределах отрезка кода между двумя sequence
> point - там нет.Согласен, оптимизатор в GCC иногда настолько суров и беспощаден, что бинарь после компиляции валится в кору, особенно если со всякими -ffast-math -O3 -funroll-all-loops -falign-* перемудрить.
> такие грабли с -O0 код работает, даем -O2 в надежде выиграть
> пару % производительности, но при этом получаем SIGSEGV сразу же после старта).а что на это говорят -Wall и valgrind?
> Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.
удивительно, не так ли? а не надо их писать, если не знаешь, какой код компилятор нагенерит.
>> такие грабли с -O0 код работает, даем -O2 в надежде выиграть
>> пару % производительности, но при этом получаем SIGSEGV сразу же после старта).
> а что на это говорят -Wall и valgrind?
>> Наиболее часто бинарники валятся после борки с оптимизацией, если в коде были ассемблерные вставки.
> удивительно, не так ли? а не надо их писать, если не знаешь,
> какой код компилятор нагенерит.Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто не обойтись, вот и приходится изощряться.
> Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто
> не обойтись, вот и приходится изощряться.в отдельную либу, её с -O0, не забыть пояснить компилятору, какие регистры дохлые.
кстати, а можно поинтересоваться: зачем инлайн-асм? именно вот вмонтированый в сишный исходник асм мне — дай демона памяти — за 10+ лет ни разу не понадобился. вообще, могу вспомнить только случаи конверсии бэкбуфера в разный BPP да софтварного текстуризатора — там пришлось асм делать.
>> Ваши бы слова да богу в уши=). Иногда без инлайнового ассемблера просто
>> не обойтись, вот и приходится изощряться.
> в отдельную либу, её с -O0, не забыть пояснить компилятору, какие регистры
> дохлые.
> кстати, а можно поинтересоваться: зачем инлайн-асм? именно вот вмонтированый в сишный исходник
> асм мне — дай демона памяти — за 10+ лет ни
> разу не понадобился. вообще, могу вспомнить только случаи конверсии бэкбуфера в
> разный BPP да софтварного текстуризатора — там пришлось асм делать.Была задачка надо было с MSR-регистрами работать с юзерленда. Отдельную либу городить - муторно, а пару __asm__ volatile () втыкнуть в код функции много проблем не доставляло.
И второй случай из недавнего читалка TSC-регистра (а-ля команда RDTSC) дабы сэкономить пару байт ( функция как раз кончалась на этой ассемблерной вставке) эпилог функции был перенесен мною в эту самую многострадальную __asm__ volatile(), с -O0 все прекрасно, даже с просто -O Segmentation Fault. Как мне кажется GCC делает оптимизацию работы со стеком и мой выкрутас поломал логику оптимимзатора ( хотя не должен был) и я получил SegFault.Ну тут может и я был ССЗБ, но как мне кажется результат все равно должен был быть удобоваримым. В задачке с TSC нужно было реализовать софтварный HPET-таймер с завязкой на Timestamp counter процессора. Пришлось в качестве решения проблемы убирать эпилог функции из __asm__() и дать компилеру построить его самому.
> И второй случай из недавнего читалка TSC-регистра (а-ля команда RDTSC) дабы сэкономить
> пару байт ( функция как раз кончалась на этой ассемблерной вставке)
> эпилог функции был перенесен мною в эту самую многострадальную __asm__ volatile(),
> с -O0 все прекрасно, даже с просто -O Segmentation Fault. Как
> мне кажется GCC делает оптимизацию работы со стеком и мой выкрутас
> поломал логику оптимимзатора ( хотя не должен был) и я получил
> SegFault.Эпилог - да, делать точно не стоило.
Просто описать команду и результаты.
Захотел попробовать скачать под ms windows-не нашёл бинарников.
Ого! Вот это новость. Я уже думал, что ту яму не найдут и не откопают. А оно эвон как вышло.
Зачем сейчас ещё один компилятор С на С? Уже десять раз бы обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали или схеме.
> Зачем сейчас ещё один компилятор С на С? Уже десять раз бы
> обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали
> или схеме.Что мелочиться, давайте уж тогда на Барсике от ZX-Spectrum напишем =)
(off) Барсик же вроде для писишек, а не спектрумов, заявляли? :)http://www.gamedev.ru/code/forum/?id=90972&page=2#m21
PS: вообще да, они б по скорости кода ещё с пресловутым 2.7.x.y сравнили...
Новые версии GCC далеко не всегда и не во всём быстрее старых (как по времени компиляции так и покачеству герерируемого кода), проверено не раз на scimark2k
> (off) Барсик же вроде для писишек, а не спектрумов, заявляли? :)
> http://www.gamedev.ru/code/forum/?id=90972&page=2#m21О, кто-то тоже видел этот доисторический "Power Saving" и "умный дом", все в одном. Новое - это хорошо забытое старое...
> (off) Барсик же вроде для писишек, а не спектрумов, заявляли? :)GLBasic
Write a program once, then compile for Windows, Apple Mac OS X. Start your iPhone development, Linux, PocketPC (Smartphone and Windows Mobile) and GP2X/Wiz without changing the source code at all.
http://www.glbasic.com/
DarkBASIC - The Ultimate 3D Games Creator
DarkBASIC allows you to create your own games, demos, slideshows, even business applications using the easy to understand BASIC programming language. Even if you've never coded before, just follow the in-depth tutorials and you'll be generating results in minutes! Harness the power of Direct X and make 3D objects come to life in just a few simple commands.
http://www.thegamecreators.com/?m=view_product&id=2030
>Что мелочиться, давайте уж тогда на Барсике от ZX-Spectrum напишемИспользуют же lex, yacc, что сейчас мешает использовать более подходящий, нежели C, способ работы с деревьями?
> Используют же lex, yacc, что сейчас мешает использовать более подходящий, нежели C,
> способ работы с деревьями?Это JavaScript или Scheme на деревья ориентированный? а получше ничего нет??
> если бы на джаваскрипте писалиУгу, так и представляю себе компилер с временем запуска оного как у браузеров... oO
> Угу, так и представляю себе компилер с временем запуска оного как у
> браузеров... oOто есть, мгновенно, как моя опера? нормально, устраивает.
> Зачем сейчас ещё один компилятор С на С? Уже десять раз бы
> обогнали всех по качеству генерируемого бинарника, если бы на джаваскрипте писали
> или схеме.1. На Javascript - точно не обогнали бы. А какая-то специфическая форма LISP у gcc внутрях, используется на всю катушку, но супер-достижений не видно. Просто почти оптимум.
2. Независимая простая реализация в качестве контрольной - обязательная штука в сложных системах. Как-то даже для сравнительно простой криптографии я писал 4 реализации: C/OpenSSL, C/GnuTLS, Python и Erlang. Зато в результате я смог каждому участнику дать все 4 и сказать "вот канонический набор реализаций, сдирай код сколько угодно, но твоя реализация должна давать идентичный результат". А компиляторы диагностировать обычно сложнее криптографии.
Обновился порт lang/pcc на FreeBSD: http://www.freshports.org/lang/pcc/