Линус подумывает о возможности перехода на другой компилятор C

>> Смешно пошутил, да.

> Нетку собирает...

На скольких платформах? И речь вроде о Линуксе >:)~

>>Скока еще народу подумало что Линус хочет соскочить с GPL?:)))

>И ты тоже подумал?))) Не, он не просто хочет соскочить, у него в некотором смысле наметилось противостояние с РМС ;-)

То что Пророк разочаровался в своем Мессии, зничит определенный рубикон пройден, это нормально. Вон, Иоанн-Креститель тоже к Иисусу ходил плакаться - Тебя ли мы ждали? - Меня, меня конечно. Возьми с полки пирожок.

Насколько я понимаю, с GPL у всех вышеперечисленных совместима только OpenWatcom License. Так что вариантов не очень много.

Есть еще tcc (tiny c compiler) под LGPL.

Линус припиарил LLVM. Сегодня они проснутся знаменитыми.

Дело-то не в компиляторе, а в языке.

У интеловского оптимизаций ещё больше, таких вещей соответственно.

Чтобы не ломать язык достаточно кстати простой прагмы, сообщающей компилятору, что "содержимое памяти могло изменится" и вставлять её(прагму) во все pthread_* функции.

Эдакий глобальный по памяти, но локальный по конкретной инструкции volatile.

> На скольких платформах? И речь вроде о Линуксе >:)~

Папа есть ? Мама есть ? Зачем такой злой ?

Дадада тока i386 и тока юзерспейс, нырять с ним в pkgsrc не рекомендуется.

>Вон, Иоанн-Креститель тоже к Иисусу ходил плакаться

А потом при ментах "Неее мужики вы че мопед не мой я тока разместил объяву"...

>that's discussable

That's disassemblibale.

мне вообще кажется что многие ошибки от компиляторов :)

>> На скольких платформах? И речь вроде о Линуксе >:)~

>Папа есть ? Мама есть ? Зачем такой злой ?

Хто злой, я злой? o_O Да я тебя процитировал ;)

> Дадада тока i386 и тока юзерспейс

О чем и спич... Хотя парень, занимающийся pcc, вроде писал и о поддержке MIPS. А еще нужно учесть, что Линукс сильно завязан на специфические фишки GCC, особенно его inline-ассемблер.

Угу... А давайте вообще перепишем ядро на FreePascal+asm. И, по крайней мере, с перполнением буфера и утечками памяти проблем не будет :)

Linux.org.ru подумывмает о вожможности перехода на другого Линуса Тордвальдса

>я то в этом проблем не вижу

в том, что о верифицируемости билд-енвайромента с закрытым компилятором можно будет забыть, тоже не видишь проблем?

Читаем по ссылке (LKML):

The gcc guys seem to be saying to mark everything volatile that could be touched in a critical section. This is insane for Linux.

Идём в Википедию (http://en.wikipedia.org/wiki/Volatile_variable):

In computer programming, a variable or object declared with the volatile keyword may be modified externally from the declaring object. For example, a variable that might be concurrently modified by multiple threads should be declared volatile. Variables declared to be volatile will not be optimized by the compiler because the compiler must assume that their values can change at any time. Note that operations on a volatile variable are still not guaranteed to be atomic.

Делаем выводы...

pppp

>Делаем выводы...

Читай /usr/src/linux/Documentation/volatile-considered-harmful.txt Why the "volatile" type class should not be used

И попробуй понять почему Линус так не хочет...

На самом деле идея форка GCC не так уже и нереальна. XFree86 еще кто-нибудь юзает? Ото ж бо. Все юзают xorg. Потому что в XFree были тормоза, который патчи с чарсетом по два года принимали и никак не хотели менять критически кривые архитектурные решения. Да, собственно, и gcc уже форкали, а потом обратно приращивали.

Так что если ребятки будут упорствовать, то всё может быть.

>The gcc guys seem to be saying to mark everything volatile that could be touched in a critical section. This is insane for Linux.

>Идём в Википедию (http://en.wikipedia.org/wiki/Volatile_variable):

>In computer programming, a variable or object declared with the volatile keyword may be modified externally from the declaring object. For example, a variable that might be concurrently modified by multiple threads should be declared volatile. Variables declared to be volatile will not be optimized by the compiler because the compiler must assume that their values can change at any time. Note that operations on a volatile variable are still not guaranteed to be atomic.

>делаем выводы..

Какие выводы? То, что изменяется из критической секции может быть не volatile. Всю жизнь не пользовался volatile, изменял разделяемые поля только захватив мьютекс и всегда все работало. Есть еще всякие InterlockedIncrement & InterlockedDecrement для вырожденных случаев.

>То, что изменяется из критической секции может быть не volatile. Всю жизнь не пользовался volatile, изменял разделяемые поля только захватив мьютекс и всегда все работало.

В том то и фишка, получается что не может. И то, что до этого работало - просто низкая вероятность сбоя. Но она отнюдь не нулевая. Посмотри http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html Тут всё обьяснено!

А сейчас как раз BSD cc (не эсэс, цэцэ) подняли, он даже уже собирает стейбл NetBSD на i386. Будем посмотреть, будем увидать.

> И попробуй понять почему Линус так не хочет...

Я в детстве тоже писал сочинения, от которых сейчас обхохотаться можно.

И что? Линус написал, что volatile не стоит использовать, потому что он мешает оптимизации. Причём писал он это, когда в процессорах не было conditional store (что тоже является оптимизацией, но на хардварном уровне). Теперь же он жалуется, что некоторые оптимизации надо отменить. Это потянет за собой внедрения в компиляторы искусственного интеллекта, который будет предугадывать мысли разработчиков.

Поскольку он не хочет следовать стандарту Си, а в комитете по стандартизации, в случае чего, его пошлют далеко и надолго, то действительно надо форкать gcc и писать компилятор для сборки ядра Linux.

> То, что изменяется из критической секции может быть не volatile. Всю жизнь не пользовался volatile, изменял разделяемые поля только захватив мьютекс и всегда все работало.

То, что вы пишете бажные программы, никоим образом вас не оправдывает.

pppp

>>> Как на что? Visual C++.
>Оно прекрасно и Си-код компилирует, даже (применительно к последним версиям можно сказать - как правило) лучше, чем GCC. Зато GCC силён в математике.


Когда оно начнёт поддерживать C99, тогда и можно будет говорить.

Даёшь нанокомпилятор. http://zeelanna.blogspot.com/2007/10/blog-post.html

>Линус подумывает о возможности перехода на другой компилятор C

Вот пусть он молча и подумывает, нечего лучшие умы ЛОРа будоражить

> А сейчас как раз BSD cc (не эсэс, цэцэ) подняли, он даже уже собирает стейбл NetBSD на i386. Будем посмотреть, будем увидать.

какой такой BSD cc? ссылку :)

LLVM круто, а ГЦЦ ф топку

>Вот я думаю тоже, а на хрена нам вообще Линус Торвальдс? Хип-хоп будет жить и без финна.

+= 2

>?Ссылки в студию

какие ссылки?! если в наспех сделанном на коленке test-case
int main()
{
int i,j,n,k[20]={0};
for(n=0;n<1000000;n++)
for(i=0;i<20;i++)
for(j=i;j<20;j++)
k[i]=k[j]+i*j;
for(i=0;i<20;i++)
printf("%i ",k[i]);
return 0;
}
GCC(4.1-svn,4.2-svn) догоняет VC7(/0x) только при -O3 -funroll-all-loops, что для большинства приложений совершенно неприемлемо? И 4.2 немного медленнее 4.1, и компилирует дольше. Ещё у GCC код больше даже без разворота циклов. А конкретно за ссылками - в багзиллу.

> какой такой BSD cc? ссылку :)

http://www.bsdcc.org/

Он _уже_ начал его писать. Давно. http://www.kernel.org/pub/software/devel/sparse/

Кстати, написать на коленке замену BitKeeper оказалось не слабо.

> http://www.bsdcc.org/

увы, не то.

> А я своего кота Линусом назвал. :)
Bohtvaroh * (*) (25.10.2007 21:45:39)

а у меня кот - Торвальдс !

торик, торик - кис-кис-кис...

http://gcc.gnu.org/c99status.html

gcc вроде ещё не поддерживает

> Поскольку он не хочет следовать стандарту Си, а в комитете по стандартизации, в случае чего, его пошлют далеко и надолго, то действительно надо форкать gcc и писать компилятор для сборки ядра Linux.

Или форкнуть самого Линуса. Благо клонирование сейчас вполне продвинулось. А потом заняться воспитанием клона, поручить это дело Ричарду Столлмену. Научить клона любить GNU, GCC и заставить писать Hurd! :)

ГНУ Эпизод 2, атака клонов?

> На самом деле идея форка GCC не так уже и нереальна. XFree86 еще кто-нибудь юзает? Ото ж бо. Все юзают xorg. Потому что в XFree были тормоза, который патчи с чарсетом по два года принимали и никак не хотели менять критически кривые архитектурные решения.

Насколько я помню форк XFree86 был обусловлен в первую очередь лицензионными соображениями.

Все, капец пингвину!


Закончится все пресс-релизом:
Sun обсуждает возможность выпуска Studio под лицензией GPL... ;-)

> Линус подумывает о переходе на другой компилятор, в связи со слишком частым повторением такой ситуации, когда разработчики gcc занимаются юридическими выкрутасами с языком (language-lawyering) вместо решения реальных проблем пользователей gcc.

Почему бы Линусу вместо того, чтобы заниматься постоянным ломанием API, выступлением против GPL, критикой гном и прочими выкрутасами не заняться решением реальных проблем пользователей Linux или попробовать написать патч для gcc устраняющий конкретные проблемы?

Ну-ну. Перейдет на другой компилятор, а там вместо одной этой проблемы получит двадцать других. Его спросят: Линус, ты же говорил "пиастры, золотые пиастры, а тут ничего нет!" :)

> Он _уже_ начал его писать. Давно. http://www.kernel.org/pub/software/devel/sparse/

Это не компилятор

> написать на коленке замену BitKeeper оказалось не слабо.

Смешно, да. Git писали десятки людей (и основной его автор уже дааавно Junio Hamano), а идеи Линус слямзил из Monotone (и OpenCM), чего и не скрывал.

Написанная на коленке замена BitKeeper - это скорее Mercurial (да и то с натяжкой).

пора переходить на ассемблер

>На самом деле идея форка GCC не так уже и нереальна.

Так некому форкать. Разработчик GCC совсем недавно жаловался, что очень мало народу принимает участие в разработке. И очень мало народу понимает вообще что-либо в компиляторе. О каких формках можно говорить при отсуствии народа даже в основной ветке? Да и потом, форк в редчайших случаях бывает успешным, так как это долгосрочная поддержка, разговор со многими людьми, каждодневная правка, проверка и т. д. Поначалу у всех огоноь горит, а как только рутина начинается, так наступает медленное угасание. Линус, если чем-то недоволен, пусть патч напишет, еслион локализовать проблему умудрился.

:) сразу под 8 платформ.

Линус как всегда жжот. И, как я понимаю, виноват не компилятор, а стандарт. Так что будь последователен, горячий финский пацан, меняй не компилятор, а язык!

>> То, что изменяется из критической секции может быть не volatile. Всю жизнь не пользовался volatile, изменял разделяемые поля только захватив мьютекс и всегда все работало.

>То, что вы пишете бажные программы, никоим образом вас не оправдывает.

ну согласен, при чтении разделяемой переменной тоже надо захватывать мутекс, это я пропустил. А volatile переменные вроде зависят от архитектуры - на 32 битовой системе 2 my mind нельзя добиться волатильности от long long и некоторых других типов?

>Давно пора Линуса куда-нибудь перевести (на свалку истории, например), а руление флагманским Open Source проектом поручить команде адекватных движению людей.

А линукс назвать анонимуксом.

>нельзя добиться волатильности от long long и некоторых других типов?

Ты видимо путаешь volatile и атомарность.

>>нельзя добиться волатильности от long long и некоторых других типов?

>Ты видимо путаешь volatile и атомарность.

А что на i386 перед каждым выфетчиванием long long'а из памяти захватывается неявный мьютекс? Или volatile для long long'а просто по тихому генерирует бажный код?

рассказ о бедном главном разработчике гсс рассмешил
опен соурс не может поддерживать в нормальном состоянии свой основной рабочий инструмент ?
не смешите меня
не хватает программистов или бабла ?
линусу надо только пальцем щелкнуть - и где-нибудь в недрах редхата тут-же появится подразделение , которое будет заниматься днем и ночью только гцц , и ничем более