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

Менять язык на C# ;-)

>Менять язык на C# ;-)

Delphi! ОДНОЗНАЧНО И БЕЗ ВАРИАНТОВ! :)

Писали бы код ядра по человечьи на стандартном Си.

Чтобы компилятор генерил нормальный код он должен быть заточен под конкретный процессор. Писали бы нормально ядро и компилили разными компиляторами под разные процессоры. Почему так нельзя? Зачем код ядра ставить в зависимость от одного, но свободного компилятора? Если в проекте gcc работае мало народу, то кто будет разгребать эти проблемы?

>Прально! ждем сообщения о прекращении разработки ядра до тех пор, пока Линус не напишет свой собственный компилятор.

Вообще-то для самого первого своего ядра Линус писал свой компилятор ;)

Linux RIP, над будет в феврале RMS сказать, что бы Hurd юзали уже .. а то этот маразматик Линус уже надоел со своими бредовыми заявлениями )))

>Linux RIP, над будет в феврале RMS сказать, что бы Hurd юзали уже .. >а то этот маразматик Линус уже надоел со своими бредовыми заявлениями

А почему Hurd? Я бы например лучше MINIX3 поюзал...вернулся бы к истокам... :)

если msvc не собирает KDE, то чем же собраны вот эти бинари http://download.cegit.de/kde-windows/kde-3.94.1/complete/ (в названиях файлов не спроста наверно суффикс -msvc поставили)

>сходил по ссылке, успокоился. А вы тут панику развели.

Ну и работай теперь целый день как дурак! :D

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

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

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

ПМС - это несколько другое, сынок, и Линус тут явно не при чём.

LTO - link time optimization, способ оптимизировать всю программу целиком, как будто компилируем не по отдельности каждый файл а слитый в один длиннющий исходник. http://gcc.gnu.org/wiki/LinkTimeOptimization

>всё ядро под GPL вообще-то... посмотрим куда он там соскочит... пусть сначало со своей дури соскочит, а то видимо забористая она у него...

Куда соскочит Линус, в какие города?
И где достать нам дури, чтоб с ним попасть туда?

> Я бы например лучше MINIX3 поюзал...вернулся бы к истокам... :)

Ну так что тебя останавливает? 8)

man mv

(это, конечно, шутка)

И чего? Эвон на HP-UX в РА-RISC-ой (не знаю на счет Итаниума) версии копилятор для ядра один (K&R), а для всего остального совершенно другой - ANSI.

адекватных и свободных при этом аналогов у GCC нет, в этом и проблема. монополизм, вид сбоку

> Я представил себе как разработчики MS Office (или Windows™) жалуются что их код не компилируется из-за бажности Visual C++ или их программы не работают в бажной винде.

Вы будете смеяться, но некоторое время назад (во времена VC5, кажется), команда MS Office поддерживала свою ветку компилятора.

(Доказательств дать не могу - инфа из устных источников.)

>Интеловский компилятор имеет ОЧЕНЬ ХОРОШУЮ поддержку возможностей интеловских процов (поддерживаются ВСЕ возможности), для совместимых процов генерит код кое-как.

Крис Касперски как-то сказал что есть прикол в том что Intel C++ код почему-то намного кошернее работает под AMD чем под Intel.

Гы. А как же могли Builder забыть? Представьте, компонент TLinuxKernel на форме :)

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

JAVA наше фсио! портабилити в массы! :)

"Словарь нанопрограммиста." http://zeelanna.blogspot.com/ Может подумать о будущем? Вот кто то машину времени перекрутил опять.

> Вы будете смеяться, но некоторое время назад (во времена VC5, кажется), команда MS Office поддерживала свою ветку компилятора.

Даже для Excel: ищите книгу Дж. Спольски "Лучшие приёмы разработки ПО"

Но Linux-то в исходниках!

так. Линус начал выёживаться. незря дядько Столман HURD делал, ой незря.

>"Лучшие приёмы разработки ПО"

Каждому приложению свой компилятор.

Когда у ОО будет свой компилятор?

тряпочный фофан? :-)

> так. Линус начал выёживаться. незря дядько Столман HURD делал, ой незря.

Linus != Linux; Если болезнь будет прогрессировать, то законность форка под GPL еще никто не отменял - а за это Столлману действительно спасибо.

>> так. Линус начал выёживаться. незря дядько Столман HURD делал, ой незря.

>Linus != Linux; Если болезнь будет прогрессировать, то законность форка под GPL еще никто не отменял - а за это Столлману действительно спасибо.

зачем форкать бред параноика ?

фигня полная. есть стандарт С и он явно говорит о том, что компилятор свободен генерить все что ему захочется если это не противоречит execution модели описанной там абстрактной машины. чтобы не было непоняток, нужно писать программы ( и компиляторы ) соответствующие стандарту - в данном конкретном случае использовать volatile. как совершенно правильно заметил Erik Trulsson

<quote> As far as the C standard is concerned, yes, the compiler is most certainly free to insert such a sequence almost anywhere.

If a variable has been declared as 'volatile' however, then all accesses to it must be according to the abstract machine defined by the C standard, i.e. the compiler is not allowed to optimize away any access to the variable, nor is it allowed to insert spurious accesses to the variable. </quote>

>Примечательно, что на возможность такого рода неприятностей с блокировками в связи с недостаточной определенностью стандартов на язык C было указано еще два года назад в статье "Threads Cannot Be Implemented As a Library" (автор: Hans Boehm)

на язык С стандарт (единственный существующий ISO/IEC 9899) определен вполне достаточно и прекрасно, только вот абстрактная машина, в рамках которой определяется поведение С программ - однопоточна, и если переупорядочения кодя компилятором можно избежать посредством volatile-ов, то memory barrier-ов там нет и предотвратить переупорядочение доступа к памяти процессором возможности нет (нужно пользоваться ассемблером).

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

volatile переменные зависят только от разработчиков компилятора.

Вы путаете волатильность с атомарностью.

pppp

> на язык С стандарт (единственный существующий ISO/IEC 9899) определен вполне достаточно и прекрасно, только вот абстрактная машина, в рамках которой определяется поведение С программ - однопоточна, и если переупорядочения кодя компилятором можно избежать посредством volatile-ов, то memory barrier-ов там нет и предотвратить переупорядочение доступа к памяти процессором возможности нет (нужно пользоваться ассемблером).

Тогда, вероятно, нужно расширить семантику слова volatile и обязать разработчиков GCC следовать ей, хотя они те еще буквоеды! :)

>> на язык С стандарт (единственный существующий ISO/IEC 9899) определен вполне достаточно и прекрасно, только вот абстрактная машина, в рамках которой определяется поведение С программ - однопоточна, и если переупорядочения кодя компилятором можно избежать посредством volatile-ов, то memory barrier-ов там нет и предотвратить переупорядочение доступа к памяти процессором возможности нет (нужно пользоваться ассемблером).

>Тогда, вероятно, нужно расширить семантику слова volatile и обязать разработчиков GCC следовать ей, хотя они те еще буквоеды! :)

У Александреску видел пример синглетона который с одной стороны не захватывает мьютекс при каждом getInstance(), а с другой гарантирует что на друхпроцессорной машине синглтон не будет инстанциирован два и более раз. Там он вроде как использовал volatile и сказал что нормальный компилятор "для машин такого класса" будет использовать "барьеры памяти или какой-либо другой спицифичный для платформы способ упорядочить доступ к памяти". Читал давно, точно не помню.

По идее так и должно быть, а иначе зачем нужен этот volatile?

откройте для себя atomic_t

И итог:
> Now all you have to do is tell this to the gcc developers ;)

We're listening, really. It's unacceptable that gcc should break
code.

> если msvc не собирает KDE, то чем же собраны вот эти бинари http://download.cegit.de/kde-windows/kde-3.94.1/complete/ (в названиях файлов не спроста наверно суффикс -msvc поставили)

Речь была не о вижуалке, а о сановской студии.

>> Интеловский компилятор имеет ОЧЕНЬ ХОРОШУЮ поддержку возможностей интеловских процов (поддерживаются ВСЕ возможности), для совместимых процов генерит код кое-как.

> Крис Касперски как-то сказал что есть прикол в том что Intel C++ код почему-то намного кошернее работает под AMD чем под Intel.

Значит, Интер допилил-таки совместимый с AMD компилятор, но не допилил совместимый с AMD процессор. Только и всего :)))))))

Сан и Микрософт тоже обратили внимание на недоделанность интеловских AMD-совместимых процов :)))))))

> Мде. Лишь бы не на яву перешли. А то тоже тема - залабать программку, которая конвертнет код с С на жабский. =) И тогда все будут ставить по 16 гигов памяти на компы. =) Лафа производителям железа.

Микрософт тут оказался первым с CLR. Боюсь, что оптимальная конфигурация системы под Висту примерно 16 гиг и требует.

>>Менять язык на C# ;-)

> Delphi! ОДНОЗНАЧНО И БЕЗ ВАРИАНТОВ! :)

питон спасёт ядро!

>питон спасёт ядро!

Лучше перейти на php ~_~
Сначала пишем на php скрипт, который из кода на php умеет генерить бинарники. Потом этим скриптом компилируем самого себя - получаем бинарный компилятор php. Ну и потом, для верности, этим компилятором собираем исходный скрипт. Итого: получаем бинарный компилятор из php в бинарники, который собран бинарным компилятором php.
Ну а дальше написать ядро на php и собрать его - дело техники.

Не надо Пыпхпых на ненадо

>>питон спасёт ядро!
>Лучше перейти на php ~_~

Это всё муть!

Давайте на Лиспе лучше всё делать. Мне его синтаксис и семантика нравятся -- на тридцати страничках подробнейшим образом в книжке ISBN 5-7913-0072-7. Это ведь не Форт какой-нибудь, а нормальный человеческий язык.

Да не надо на это всё много внимания обращать, помнитса Линус когдато рванулса на паскаль перейти. К стати конверторы c2pas есть какието, также имеетса fpc - чем не альтернативный путь:)

А то что разработчиков gcc пинать надо чтобы лучший код давали то это правильно, пусть Линус их пинает...

А вот я соглашусь с Линусом - в архиве рассылки LKML он четко изложил свои мысли. Полностью соглашусь...

>это бесполезно - сделаем ребрендинг, и будет чтото типа leenooks

"Lee'n'Ooops!"

кто больше?

> Мде. Лишь бы не на яву перешли.

А почему бы и не? Универсальное кроссплатформенное JIT-компилируемое ядро -- мечта энтерпрайза...

openwound:

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

Золотые слова.

GMS:

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

anonymous:

> Delphi! ОДНОЗНАЧНО И БЕЗ ВАРИАНТОВ! :)

anonymous:

> также имеетса fpc - чем не альтернативный путь:)

Народ! Почему Аду не знаем?! После создания Ады историческая миссия Паскаля была завершена. А вы всё на Паскале. Я понимаю, что в школах/универах, в отличие от более продвинутой Европы и Америки, до сих пор дают Паскаль, но кроме школ/университетов самообразованием можно же заниматься. Изучайте Аду, и на Паскаль возвращаться не захочется.

Проект пользовательской операционки на Аде есть, Lovelace OS, но у него 4 разработчика (для сравнения, у Psi семь). Присоединяйтесь, коли не шутите ;)

iZEN:

> Это всё муть!

> Давайте на Лиспе лучше всё делать.

ВСЁ не получится (планировщик потоков на Лиспе, ога).

Но кое-что на Лиспе было бы интересно. LispFS, например. Гибко задавать права доступа Lisp выражениями, кэшируя частые запросы. Описывать установленный софт Lisp выражением. То есть, Lisp выражение первично, а то, что на физическом диске лежит, ему соответствует -- это своего рода кэш. При этом кэшированием может быть что угодно, компиляция (из ebuild), скачка из репозитория, и т. д. Поставить софтварь? Легко. Просто добавить запись в нужный список на LispFS, и оно уже стоит. Закешируется (читай: откомпилируется или скачается из репозитория), и можно запустить. Но при этом кеш вторичен, а Lisp список первичен. Любой дистриб описывается Лисп выражением. То, что из себя представляет система, можно смотреть в читабельном виде. Посмотришь на это Лисп-выражение, и видишь : у меня дистриб Линукса (или не Линукса) такой-то, в котором доустановлено то-то и то-то, и все его зависимости. Автоматическое обновление? Легко. В нужном Лисп-выражении в качестве версии текущая версия по умолчанию, и Лисп-выражение периодически пересчитывается и перекэшируется. Централизованное управление софтом на нескольких одинаковых компьютерах? Легко. Указать в качестве Lisp-выражения eval от Lisp-выражения, которое нужно запросить с центрального сервера. Потенциал LispFS безграничен.

yusri:

> Нужно тогда присмотреться к диалекту cyclone. Может быть сейчас на ранней стадии присоединится к проекту и ГНУть свою линию (специфичные для ведра вещи). http://cyclone.thelanguage.org/

Нет, не нужно. Эти малые всё правильно понимают, и совершенно верно определили, что так не может продолжаться дальше. Но, обратите внимание :

http://cyclone.thelanguage.org/wiki/Why%20Cyclone

> Cyclone thus tries to fill an empty niche: the safe language that with C?s level of control and efficiency.

ПУСТУЮ НИШУ?!!! Все из себя такие-растакие Колумбы-первооткрыватели, блин. Зачем плодить сущности? Уровня Ады по гибкости и производительности всё равно не достигает.

'Cyclone', a safer C--reinventing the wheel :

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/beb0b7471c6...

Их изыскания на тему внедрения ML фич в язык, конечно, прикольны, по почему-то я предпочитаю стабильный, проверенный годами язык, современный язык с будущим. Я предпочитаю Аду.

Да что ты зациклился на своей Аде? На неё легко перевести ведро?
Как тут распинался единорог в теме про прибыль мозиллы: Линуксом двигают крупные компании, они решают в каком направлении идти, т.к. снабжают проекты профессиональными фултайм-разработчиками.
И как говорилось выше Линуксу нужно показать пальцем и РХ, Новель, ИБМ отпинают своих разработчиков или перекинут их в другой проект, если узнают что есть угроза дальнейшему развитию ядра. Если надо то и циклон воскресят.

А она есть, в т.ч. из-за недостатков языка, но переход должен быть как можно менее болезненным, на какой-нибудь диалект, а не на совершенно другой язык

Жаль, что такой серьёзный проект как GCC уже давно в анабиоза, я наверное на днях установлю 3.х, а то постоянные ухудшения (особенно производительности) достали (да, я гентушник :D)

> Да что ты зациклился на своей Аде?
Видимо, есть, за что ;)

> а то постоянные ухудшения (особенно производительности) достали
в частности, компилировать исходные тексты на Аде
(и вообще, много на чём) быстрее

> А она есть, в т.ч. из-за недостатков языка, но переход должен быть
> как можно менее болезненным, на какой-нибудь диалект, а не на
> совершенно другой язык
> Если надо то и циклон воскресят. 
Совершенно другой язык -- это Пролог.

Как перейти на Аду? Начать писать всё новое на Аде, постепенно
переписывая и старый код.
Как перейти на Cyclone? Начать писать всё новое на Cyclone,
постепенно переписывая и старый код.

Найдите 10 отличий. А если не видно разницы, то зачем платить
больше? Зачем отказываться от проверенного годами ЯП в
пользу академической игрушки?