LINUX.ORG.RU

Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.


0

0

В недавней дискуссии в lkml Linus Torvalds заявил, что он согласен отказаться от использования GCC в пользу более быстрого и маленького C копилятора (если такой появится) и согласен изменить кернел в плане отказа от использования gcc extension. Линус утверждает что проблема с GCC заключается в том что основной девелопмент и оптимизация ведется в C++, Ada, Fortran и другихх направлениях,, в то время как обычный C уже никого (из gcc девелоперов) не интересует, и большинство недавно добавленных оптимизаций не имеют никакого смысла для проэктов написанных на C.

Итак, дело за малым, у кого есть маленький и быстрый C компилятор, который умеет инлайновый ассемблер и инлайновые функции? (кроссплатформенность необязательна, но желательна).

>>> Письмо Линуса в lkml

★★★★★

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

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

anonymous ()

Re: Re: Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

>На счёт Борландов: Delphi компилит прекрасно, сам потом дизассемблил и смотрел

Это ты смешно пошутил... Вот и сравни скорость проги скомпиляной дельфями и gcc. Будешь неприятно удивлён, раз ты такой любитель дельфей.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

/Dmitry и green - имхо, оба глупцы.

Каждый сам поймет или объяснять нужно?
Hint: 2/Dmitry (green - отчасти прав), 2green - с каких пор документация и скрипты компилятся (неплохо ты об этом умолчал).

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Мне не надо ничего объяснять, я никому ничего не пытался доказать, а просто демонстрировал данные (замеры времени компиляции) по конкретным задачам которыя я использую.

Речь ведь идет о компиляторах...

А green просто флеймер и решил повыступать.

-- /Dmitry

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

s/которыя/, которые/

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Смотря в чем документация.

jackill ★★★★★ ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

http://www.goof.com/pcg/ - Были энтузиасты, которые делали это бесплатно. Они оптимизировали GCC 2.95.x под пентиумы, жаль что бросили ... Остался только "PGCC 2.95.2.1".

anonymous ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Без -O (-O0) скомпилировать нельзя. Не компилируется без специальных патчей.

green ★★★★★ ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

А что, в /usr/src/sys нет документации? Ну ладно. Тогда 6 мегабайт вычеркиваем. Скрипты - вообще копейки, ну да ладно, еще пол мегабайта вычеркиваем. ;)
> du -ks /usr/src/linux-2.4.20-quota/Documentation
6093 /usr/src/linux-2.4.20-quota/Documentation
> du -ks /usr/src/linux-2.4.20-quota/scripts/
418 /usr/src/linux-2.4.20-quota/scripts

green ★★★★★ ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Ребят, я согласен с теми, кто делает упор в этой теме именно на оптимизацию кода генерируемого GCC. У gcc есть один большой плюс от которого не уйдешь - кроссплатформенность. Но по оптимизации у него сплошные минусы. Например самый быстрый код у gcc в большинстве случаев получается не при -O3 (оптимизация по скорости выполнения), а при -Os (оптимизация по размеру). Про x86 не берусь говорить, но для ARM это так и есть. Хотя и для x86 наверняка тоже самое. А то сколько длится процесс компиляции - это не так важно, даже при разработке. Если призадуматься, то можно оптимизировать количество компиляций %) И в gcc 3.2 на сколько я помню всё таки добавили предкомпилированные заголовки, которые очень даже сокращают время компиляции. Лично меня также как и Линуса не устраивает код генерируемый gcc на данный момент. Все конечно понятно, что халява и тд. Но при такой раскладке, когда у меня на ASMе код получается в два раза меньше и быстрее, чем из C генерирует gcc, то приходится уже задумываться насчёт смены компилятора.

vitta ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Вообще, это злополучное высказывание Линуса мне напоминает высказывание в духе "а вот если бы были такие самолёты, что взлетают с места, летают 5000 км/ч и ещё тратят топлива 5л на 100 км, я бы летал такими самолётами". Другими словами, это общий трёп в духе благих пожеланий.

И я удивляюсь, как все серьёзно к нему отнеслись...

tilde

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

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

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

tilde

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

В том то и дело, что ядро не надо подстраивать. Есть C стандарты - их и надо придерживаться при разработке любого софта. Дело компилятора перевести код написаный на каком-либо алгоритмическом языка в понятный контуперу (машынный). В этом вся загвоздка. GCC с этой задачей справляется очень плохо.

А то, что алтернативы GCC нет - это ты зря. Кроссплатформенность на самом деле мало кому нужна. Для переноса софта на другую платформу, достаточно взять компилятор для этой платформы.

Кстати!
1. Кто-нибудь пробовал компилировать ядро не GCC?!
2. Кто-нибудь собрал GCC с поддержкой сразу нескольких платформ? А то у меня стоит два GCC - один для Intel'а, другой для ARM'а %(

vitta ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Есьт уже не одна ссылка на народл который собирал ядро с помощью Intel CC.

green ★★★★★ ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Ну собрали с помощью icc. И где восторженные крики о том, как он рулит? Видимо, результат не оправдывал ожидания.

tilde

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> В том то и дело, что ядро не надо подстраивать. Есть C стандарты - их и надо придерживаться при разработке любого софта. Дело компилятора перевести код написаный на каком-либо алгоритмическом языка в понятный контуперу (машынный). В этом вся загвоздка. GCC с этой задачей справляется очень плохо. Дело в том, что ядро - это не любой софт. Стандарт Си определяет минимальные требования, которым _должен_ удовлетворять компилятор. В ядре требуется выжать максимум производительности, и использование расширений вполне оправдано.

Многие вещи в стандарте вообще не определены. Например, использование встроенного ассемблера. Без которого некоторые фрагменты ядра всё же не могут обойтись.

> GCC с этой задачей справляется очень плохо.

GCC с этой задачей справляется вполне хорошо. Человек, естественно, справился бы лучше, но, по понятным причинам, это экономически неприемлимо. А по сравнению с другими компиляторами проигрыш gcc (если он вообще есть) на типичных приложениях составляет не разы, а проценты.

tilde

anonymous ()

Re: Re: Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Вы бы это разработчикам ресурсоёмкого софта сказали (типа игр, графика, рендеринг и прочее)... Если бы не оптимизация, сейчас бы играли в тетрис минимум на P4 :)

Сколько процентов разработчики игр составляют от общего числа программистов? Не надо пытаться меня удивить таким "контрпримером", я про массы говорю, а исключения всегда существуют.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> И еще, насчет MSVC. Хороший компилер, не надо на него бочку катить,
> особенно основываясь на той идее что M$ = фуфло. Что собсно далеко
> не всегда верно.
> Експериментаторам - возмите каку числодробилку (тест минут этак на
> 10) с кучей циклов, скомпилите gcc & VC6

числодробилку, смешно
вот такой простенький цикл:

#define PNL_REDUCEOP_LOOP_STEP( k ) \
++stats[k]; \
j += steps[k];

#define PNL_REDUCEOP_LOOP_CHECK( RANGES, NUM_STATS ) \
for ( k = NUM_STATS - 1; stats[k] == RANGES[k]; ) \
{ \
stats[k] = 0; \
j -= backsteps[k--]; \
PNL_REDUCEOP_LOOP_STEP( k ); \
}

#define PNL_REDUCEOP_LOOP( ACTION, INITVAL ) \
for ( i = new_bulk_size; i--; ) \
{ \
new_bulk[i] = INITVAL; \
} \
for ( i = 0, j = 0; i < bulk_size; ++i ) \
{ \
PNL_REDUCEOP_LOOP_CHECK( ranges, num_dims ); \
ACTION( new_bulk[j], bulk[i] ); \
PNL_REDUCEOP_LOOP_STEP( num_dims - 1 ); \
}

#define PNL_REDUCEOP_LOOP2( ACTION, PIVOT ) \
for ( i = 0, j = PIVOT; i < new_bulk_size; ++i ) \
{ \
PNL_REDUCEOP_LOOP_CHECK( new_ranges, num_dims_to_keep ); \
ACTION( new_bulk[i], bulk[j] ); \
PNL_REDUCEOP_LOOP_STEP( num_dims_to_keep - 1 ); \
}

компилим его в VC без оптимизации, все нормально работает, компилим с оптимизацией, сперва тоже вроде работаем, компилим его с неким SP4 и имеем сегфолт -- меняем одну переменную цикла на volatile -- опять идиллия. Да, очень хорошо подходит VC для числодробилок..

dilmah ★★★★★ ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

>2. Кто-нибудь собрал GCC с поддержкой сразу нескольких платформ? >А то у меня стоит два GCC - один для Intel'а, другой для ARM'а %(

Нельзя. У меня стоит кроме этих еще и для AVR. Но они друг другу не мешают.

smartly ★★★ ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Многие вещи в стандарте вообще не определены. Например,
> использование встроенного ассемблера. Без которого некоторые
> фрагменты ядра всё же не могут обойтись.

А ты сам стандарт читал или как?

J.5.10 The asm keyword
The asm keyword may be used to insert assembly language directly into
the translator output (6.8). The most common implementation is via
a statement of the form:

    asm ( character-string-literal );

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Не смеши мои тапочки. И это ты считаешь достаточным, чтобы писать ассемблерные вставки?

Ты по английски понимаешь? Тебе говорят, что "а вообще-то бывает такое слово asm, которое некоторые используют для встроенного ассемблера, а у некоторых этот asm даже имеет вид (см. выше)". Сравни, например, с описанием семантики оператора for и почувствуй разницу.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

И ещё, сравни реализацию этого asm в Борланде, Майкросовте и в Gcc и тоже почувствуй разницу.

tilde

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Не смеши мои тапочки. И это ты считаешь достаточным, чтобы писать
> ассемблерные вставки?

Ассемблерные вставки - это прямой путь к потере портабельности. Кроме
того, язык программирования C - это всё таки не язык ассемблера,
поэтому стандарт, описывающий язык программирования C, совсем не
обязан описывать язык ассемблера.

> Ты по английски понимаешь? Тебе говорят, что "а вообще-то бывает
> такое слово asm, которое некоторые используют для встроенного
> ассемблера, а у некоторых этот asm даже имеет вид (см. выше)".
> Сравни, например, с описанием семантики оператора for и почувствуй
> разницу.

Если ты внимательно читал стандарт, то должен знать, что раздел J.5
описывает необязательные и непортабельные расширения языка C которые,
однако, получили широкое распространение. Стандарт не запрещает (хотя
и не рекомендует) такие расширения, но он их стандартизирует. Если ты
не понимаешь по английски, то вот тебе мой перевод:

===== перевод ====
J.5.10 Ключевое слово asm
Ключевое слово asm может использоваться для прямых вставок языка ассемблера в вывод транслятора (6.8). Наиболее приемлемая реализация
- посредством инструкции следующей формы:

    asm ( литерно-стринговая-константа );
===== перевод ====

> И ещё, сравни реализацию этого asm в Борланде, Майкросовте и в Gcc
> и тоже почувствуй разницу.

У Borland-а она не соответствует стандарту, у Microsoft-а вообще нет
реализации asm (по крайней мере в VC6, как с этим в 7 пока не знаю).
GCC в этом отношении соответствует стандарту, у него правильная
реализация. Но зачем ты мне предлагаешь сравнивать эти три
компилятора? Это как-то связано с обсуждением стандарта или
компиляции Linux?

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Не смеши мои тапочки. И это ты считаешь достаточным, чтобы писать
> ассемблерные вставки?

Ассемблерные вставки - это прямой путь к потере портабельности. Кроме
того, язык программирования C - это всё таки не язык ассемблера,
поэтому стандарт, описывающий язык программирования C, совсем не
обязан описывать язык ассемблера.

> Ты по английски понимаешь? Тебе говорят, что "а вообще-то бывает
> такое слово asm, которое некоторые используют для встроенного
> ассемблера, а у некоторых этот asm даже имеет вид (см. выше)".
> Сравни, например, с описанием семантики оператора for и почувствуй
> разницу.

Если ты внимательно читал стандарт, то должен знать, что раздел J.5
описывает необязательные и непортабельные расширения языка C которые,
однако, получили широкое распространение. Стандарт не запрещает (хотя
и не рекомендует) такие расширения, но он их стандартизирует. Если ты
не понимаешь по английски, то вот тебе мой перевод:

===== перевод ====
J.5.10 Ключевое слово asm
Ключевое слово asm может использоваться для прямых вставок языка
ассемблера в вывод транслятора (6.8). Наиболее приемлемая реализация
- посредством инструкции следующей формы:

    asm ( литерно-стринговая-константа );
===== перевод ====

> И ещё, сравни реализацию этого asm в Борланде, Майкросовте и в Gcc
> и тоже почувствуй разницу.

У Borland-а она не соответствует стандарту, у Microsoft-а вообще нет
реализации asm (по крайней мере в VC6, как с этим в 7 пока не знаю).
GCC в этом отношении соответствует стандарту, у него правильная
реализация. Но зачем ты мне предлагаешь сравнивать эти три
компилятора? Это как-то связано с обсуждением стандарта или
компиляции Linux?

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

/Dmitry и green:
Вам не кажется, что начав оправдываться, Вы сели в еще большую лужу.
2green:
когда порадуешь нас новыми сплетнями ? так глядишь и до рассказов бабушек, сидящих на лавочке, дойдем.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

У меня тут вопросик родился, оффтопичный правда, но все-же :)

Никто не пробовал собрать mplayer допустим с помощью icc и сравнить по скорости работы с gcc? или у mplayer-а код слишком много фич gcc-шных использует?

Просто сам по себе mplayer занимается большим количеством числодроблений (насколько я понимаю) и было бы неплохо, если бы собравшись под icc он стал еще более летать ;) (а для моего камушка в 366MHz это порой актуально, есть фильмы которым ну никак не хватает проца, несмотря на все извраты.... ;)

sseREGa ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

sseREGa: могу попытаться, только у меня атлон, так что не понятно как оценить выигрыш производительности :) встречное предложение --- не поделишься своими "хитростями" и "извратами" по поводу добивания от mplayer приемлимой скорости на твоей железяке, а также подробностями про камень/видюху?

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

По поводу стандарта и асма. Что ты не знаешь английский, я уже понял. Поясняю: "the most common implementation" - это "наиболее распространённая реализация".

Borland _не противоречит_ стандарту, ибо см. выше. Хоть его реализация не такая, как наиболее распространённая, она не запрещается стандартом.

Кроме того, Gcc очень сильно расширяет даже синтаксис, указанный в стандарте. Если не знаешь, info gcc. В двух словах: gcc позволяет указывать входные, выходные и временные регистры, используемые в ассемблерной вставке.

Как это относится к ядру? Да очень просто. Сейчас некоторые критические по времени функции реализованы в виде inline (или даже макросов), которые используют встроенный ассемблер gcc. Предположим, что вдруг мы решили использовать супер-пупер компилятор X. Перед нами две альтернативы: либо полностью отказаться от gcc, либо поддерживать две версии того же асма для каждого компилятора. Первая альтернатива неприемлима по политическим, вторая - по техническим причинам.

Получается, что этот гипотетический компилятор должен быть _полностью_ совместим по входному языку, как сейчас декларирует icc. А теперь найдите для каждой из поддерживаемых двух десятков архитектур компилятор, полностью совместимый по входному языку с gcc.

А с icc - другая проблема: он закрыт. В настоящее время он официально неприемлим по политическим причинам. Поэтому я говорил, что gcc в настоящее время реальной альтернативы нет.

Получается, что стандарт Си не имеет к ядру никакого отношения, но и не я первый о стандарте заговорил.

tilde

anonymous ()

Re: Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

2 anonymous (*) (2003-02-08 05:48:11.601):

В общем извраты довольно простые сами по себе ;)

изврат номер раз - собрать всю систему с оптимизацией под конктерное железо (раньше у меня был AMD k6-II 375MHz, но он щас не используется по причине глючной матери, но на нем это дале __существенный__ (на мой взгляд) прирост производительности по сравнению с тем что я видел в RH7.3, на данный момент у меня Cel 366MHz, на данном камушке это уже особо не заметно, так как многие дистры щас собраны под i686 (Щас у меня Gentoo)).

Два - опробовать все возможные vo, и выбрать то что быстрее всего работает ;) У меня -vo vesa показала себя лучше всех. (правда с ней глюк один наблюдается - при выходе mplayer переключает режим в 80x25 и устанавливает там походу аж дефолтнобиосовские фонты, но это лечится одной командой, запущеной после mplayer-a ;)

Три - отрубить нафиг cache, довольно часто помогает, хотя поскольку по большей части я смотрю фильмы из локалки то из этого получаются другие лаги иногда ;)

Четыре - framedrop ;)

Пять - для особых извращенцев - hardframedrop ;))

Ну и можно перед просмотром фильма сказать top и посмотреть кто что кушает, сказать им kill -STOP хотя-бы, что-бы не убивать начисто ;) (к примеру опера на моем проце просто вися в памяти кушает процентов 10 постоянно, в режими когда ничего особо и не делает, а просто пара страничек открыто, пусть даже она и свернута ;)

Железо - проц Celeron 366MHz (на 66 FSB есессено ;), 160MB рамы, но ее хватает, видюха - ATI Rage II+ с двумя метрами видео памяти на борту ;)

sseREGa ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> По поводу стандарта и асма. Что ты не знаешь английский, я уже
> понял. Поясняю: "the most common implementation" - это "наиболее
> распространённая реализация".

Неужели? Как же это я сразу не понял, что ISO/IEC 9899:1999 - это не
международный стандарт языка программирования C, а популярная книжка
или журнал для начинающих, где неискушённым читателям рассказывают о
том что и где распространено. Учись переводить по смыслу и со смыслом.
Если стандарт описывает некое ключевое слово, то не для того чтобы ты
узнал как часто и в какой форме его используют, а для того чтобы
указать как это делать всем, кто желает собдюдать этот самый стандарт.
Вот тебе о том же ключевом слове, но уже из стандарта C++:

7.4 The asm declaration                                     [dcl.asm]
An asm declaration has the form

    asm-definition:
               asm ( string-literal ) ;

The meaning of an asm declaration is implementation-defined.
[Note: Typically it is used to pass information through the
implementation to an assembler. ]

> Borland _не противоречит_ стандарту, ибо см. выше. Хоть его
> реализация не такая, как наиболее распространённая, она не
> запрещается стандартом.

Borland сохраняет совместимость вниз с самим собой. Кстати, кроме
ключевого слова asm он имеет _asm и __asm, которые (все три) являются
синонимами. Microsoft, в этом плане, более соответствует стандарту.
У них нет реализации asm, но есть реализации _asm и __asm.
Стандарт не декларирует что он запрещает, он декларирует то, что он
разрешает и каким образом. Тоесть, всё что не разрешено - запрещено
или нестандартно.

> Кроме того, Gcc очень сильно расширяет даже синтаксис, указанный в
> стандарте. Если не знаешь, info gcc. В двух словах: gcc позволяет
> указывать входные, выходные и временные регистры, используемые в
> ассемблерной вставке.

GCC может сильно расширять что угодно, однако нужно уметь правильно
им пользоваться. Посмотри описание следующих его ключиков: -std=c99
и -std=iso9899:1999, а также -std=gnu89, использование которого
предполагается по умолчанию. Пока GCC не имеет полной поддержки
ISO/IEC 9899:1999 стандарта, но работа в этом направлении ведётся.
Предполагается, что когда она будет завершена, по умолчанию будет
использоваться ключь -std=gnu99. В любом случае, GCC может работать
в режиме полного соответствия стандарту (пока C89) без расширений.
Наличие такого режима неслучайно. Разработчики GCC сами признают, что
иногда их расширения конфликтуют с стандартом.

> Как это относится к ядру? Да очень просто. Сейчас некоторые
> критические по времени функции реализованы в виде inline (или даже
> макросов), которые используют встроенный ассемблер gcc.
> Предположим, что вдруг мы решили использовать супер-пупер
> компилятор X. Перед нами две альтернативы: либо полностью
> отказаться от gcc, либо поддерживать две версии того же асма для
> каждого компилятора. Первая альтернатива неприемлима по
> политическим, вторая - по техническим причинам.

Если программирование на языке ассемблера - единственный выход, то
будь готов к потере портабельности. Кстати, совсем не обязательно
использовать встроеный в GCC ассемблер и ключевое слово asm совсем
не означает только такое использование.

> Получается, что этот гипотетический компилятор должен быть
> _полностью_ совместим по входному языку, как сейчас декларирует
> icc. А теперь найдите для каждой из поддерживаемых двух десятков
> архитектур компилятор, полностью совместимый по входному языку с
> gcc.

Входной язык C-компилятора - это язык C. Стандарт языка C декларирует
как в C программах делать вставки на языке ассемблера, но сам язык
ассемблера и его связь с C программой стандарт не декларирует. Я уже
говорил, что использование ассемблера (любого) влечёт за собой потерю
портабельности. Более красивым дизайном ядра, с точки зрения
портабельности, был бы такой, при котором ассемблерные и C функции
чётко разграничены и разнесены в соответствующии файлы. Тоесть в *.c
файлах только C код, без всяких asm, а ассемблерный код в *.S или
*.asm файлах. Тогда перенос на новую платформу будет заключаться лишь
в переносе ассемблерного кода, которого в UNIX должно быть немного,
по определению.

> А с icc - другая проблема: он закрыт. В настоящее время он
> официально неприемлим по политическим причинам. Поэтому я говорил,
> что gcc в настоящее время реальной альтернативы нет.

По политическим? Его в ООН обсуждали и наложили санкции? :-))
Ты наверно имел в виду идеологическии причины. Да, есть такая странная
идеология - GNU GPL. И хотя мне эта идеология не нравится, я всё таки
не вижу ничего плохого в использовании GCC. Также я не вижу ничего
плохого в использовании любых других C компиляторов, которые
соответствуют стандарту. Другое дело, что пока мало компиляторов
полностью поддерживающих последнюю редакцию стандарта языка C. Поэтому
пока следует ограничиваться предпоследней редакцией и постепенно
переходить к последней. GCC как раз позволяет это делать.
Он мультиплатформенный и продолжает развиваться в сторону соответствия
стандарту языка C в его последней редакции.
Что же касается ICC, то мне абсолютно начхать на его закрытость. Всё
что мне от него прежде всего надо - уметь правильно компилировать C
код, который написан в соответствии со стандартом. ICC является платформо-специализированым компилятором, поэтому его использование на
данной платформе имеет неоспоримые преимущества по сравнению с обычным
компилятором.

> Получается, что стандарт Си не имеет к ядру никакого отношения, но
> и не я первый о стандарте заговорил.

Получается как как раз наоборот. Разумеется если мы говорим о ядре
UNIX-like операционной системы, одним из основных качеств которой
является портабельность.

Именно поэтому я против какого-то специального кернел-компилятора.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Ну вот кстати и фишка: Сегодня подоспел релиз сорцов OpenWatcom 1.0. Какие прогнозы?

Mossy ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Учись переводить по смыслу и со смыслом.

Стандарт - это нормативный документ, формулировки в котором тщательно подбираются годами. Его нужно читать так, как там написано, а не так, как хочется. Ещё раз повторю, что "the most common implementation" - это "наиболее распространённая реализация", а не "наиболее приемлимая реализация". Посмотрите в словарь, наконец.

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

См. введение в стандарт (не помню точно номер параграфа). Там ясно написано, что цель данного стандарта не только ввести общие правила, обязательные для реализации, но и "кодифицировать имеющуюся практику".

> Вот тебе о том же ключевом слове, но уже из стандарта C++

А причём здесь C++? Это другой язык, разрабатываемый совсем другим комитетом по стандартизации.

> Borland сохраняет совместимость вниз с самим собой.

Мы о соответствии стандарту, или о совместимости?

> Стандарт не декларирует что он запрещает, он декларирует то, что он разрешает и каким образом. Тоесть, всё что не разрешено - запрещено или нестандартно.

В начале каждого стандарта есть раздел о терминах. Там определяются термины "must", "may", "implementation-defined" и пр. После этого все модальные слова должны в стандарте читаться однозначно.

Кроме того, из более ранней реплики (Вашей?): "Стандарт не запрещает (хотя и не рекомендует) такие расширения". Следовательно, реализация Borland не противоречит (а значит и соответствует стандарту).

> "...но сам язык ассемблера и его связь с C программой стандарт не декларирует."

А нам-то это требуется (связь ассемблера с Си). Здесь стандарт всё отдаёт на усмотрение реализации. Сооветственно, мы пользуемся тем, как это реализовано в Gcc.

> Более красивым дизайном ядра, с точки зрения портабельности, был бы такой, при котором ассемблерные и C функции чётко разграничены и разнесены в соответствующии файлы.

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

> По политическим? Его в ООН обсуждали и наложили санкции? :-))

А политика только с ООН ассоциируется? Пойдите на домашнюю страницу RMS. Там Вы найдёте раздел "политические выступления", в котором собраны его выступления по поводу свободного софта. Я это пишу к тому, что слово "политика" имеет широкий смысл, который, в частности, включает в себя и идеологию.

> ICC является платформо-специализированым компилятором, поэтому его использование на данной платформе имеет неоспоримые преимущества по сравнению с обычным компилятором.

Я то же самое говорил ранее. Я совершенно не против того, чтобы частные лица использовали какой угодно компилятор для компиляции ядра. Да хоть секретный компилятор ФСБ (если таковой имеется - но не в этом суть). Но _официальная_ ориентация на несвободные ко мпиляторы политически неправильна.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> > Учись переводить по смыслу и со смыслом.
>
> Стандарт - это нормативный документ, формулировки в котором
> тщательно подбираются годами. Его нужно читать так, как там
> написано, а не так, как хочется. Ещё раз повторю, что "the most
> common implementation" - это "наиболее распространённая
> реализация", а не "наиболее приемлимая реализация". Посмотрите в
> словарь, наконец.

Посмотрите и вы, предлагаю словарь lingvo.yandex.ru и в поле ввода
введите словосочетание "most common".

> > Если стандарт описывает некое ключевое слово, то не для того чтобы
> > ты узнал как часто и в какой форме его используют, а для того
> > чтобы указать как это делать всем, кто желает собдюдать этот
> > самый стандарт.
>
> См. введение в стандарт (не помню точно номер параграфа). Там ясно
> написано, что цель данного стандарта не только ввести общие
> правила, обязательные для реализации, но и "кодифицировать
> имеющуюся практику".

Я в курсе и я не утверждал, что ключевое слово asm обязательно для
реализации. А что вы хотели сказать фразой "кодифицировать имеющуюся
практику"?

> > Вот тебе о том же ключевом слове, но уже из стандарта C++
>
> А причём здесь C++? Это другой язык, разрабатываемый совсем другим
> комитетом по стандартизации.

Да, я в курсе всего этого. Просто язык C++ появился на свет как
надмножество языка C. Как мне кажется, ключевое слово asm попало в
стандарт языка C++ из стандарта языка C. Единственое что их различает
- это обязательность для реализации.

> > Borland сохраняет совместимость вниз с самим собой.
>
> Мы о соответствии стандарту, или о совместимости?

Мы вообще-то о том, как правильно программировать на языке C, например
ядро UNIX-like операционной системы. Про Borland не я первым начал.

> > Стандарт не декларирует что он запрещает, он декларирует то, что
> > он разрешает и каким образом. Тоесть, всё что не разрешено -
> > запрещено или нестандартно.
> 
> В начале каждого стандарта есть раздел о терминах. Там определяются
> термины "must", "may", "implementation-defined" и пр. После этого
> все модальные слова должны в стандарте читаться однозначно.

Да, есть там такое: "3. Terms, definitions, and symbols", и что?
Какой термин, из там перечисленых, я понял неверно?
Не останавливайтесь на пол пути, доведите свою аргументацию до конца.

> Кроме того, из более ранней реплики (Вашей?): "Стандарт не
> запрещает (хотя и не рекомендует) такие расширения". Следовательно,
> реализация Borland не противоречит (а значит и соответствует
> стандарту).

Реплика моя, но реплика не вся. Вот всё то предложение целиком:
"Стандарт не запрещает (хотя и не рекомендует) такие расширения, но
он их стандартизирует". Вас явно ввело в заблуждение слово
"расширения" и поэтому вы поспешили отбросить ту часть предложения,
что после запятой, а зря. Перечитайте что я говорил в том посте,
из которого вы вырвали часть моего предложения. Я говорил там о
расширениях признаных стандартом, а не введёных Borland-ом или кем-то
другим. Стандарт стандартизирует (простите за каламбур) упомянутые в
нём расширения, но он не декларирует их как обязательные. Неужели это
так трудно понять?
Поэтому реализация asm компанией Borland противоречит стандарту.
Более того, даже двум стандартам одновременно!

> > "...но сам язык ассемблера и его связь с C программой стандарт не
> > декларирует."
>
> А нам-то это требуется (связь ассемблера с Си). Здесь стандарт всё
> отдаёт на усмотрение реализации. Сооветственно, мы пользуемся тем,
> как это реализовано в Gcc.

Вы явно не различаете связь ассемблера с C-программой и связь
C-программы с ассемблером. Про первую должен заботиться ассемблер и
стандарту языка C это неинтересно. Небольшая подсказка: посмотрите
описание ключевого слова volatile и подумайте для чего оно необходимо.
Про вторую связь вполне чётко написано в стандарте. Там описано как
реализовать передачу ассемблеру ассемблерного кода из C программы.

> > Более красивым дизайном ядра, с точки зрения портабельности, был
> > бы такой, при котором ассемблерные и C функции чётко разграничены
> > и разнесены в соответствующии файлы.
>
> Было бы, конечно. И везде, где можно, так делается. Но такое
> решение неудовлетворительно из-за потерь в производительности.

Из-за нежелания потерь в производительности можно переписать ядро UNIX
на языке ассемблера конкретной платформы. UNIX изначально именно так
и был написан, однако очень быстро его, почти полностью, переписали
на C. При этом отцы-основатели UNIX потеряли порядка 20..30% (точные
значения не помню) от производительности. И это во времена PDP-11!
Насколько я знаю, ключевое слово asm в *.c ими не использовалось.

> > По политическим? Его в ООН обсуждали и наложили санкции? :-))
>
> А политика только с ООН ассоциируется? Пойдите на домашнюю страницу
> RMS. Там Вы найдёте раздел "политические выступления", в котором
> собраны его выступления по поводу свободного софта. Я это пишу к
> тому, что слово "политика" имеет широкий смысл, который, в
> частности, включает в себя и идеологию.

Странно, а вот в http://www.stallman.org/#politics ясно написано:
"This is a list of my political articles that are not related to the
GNU Project. For GNU-related articles, see the GNU philosophy
directory" и линк на http://www.gnu.org/philosophy/
Ещё есть http://www.stallman.org/#notes но и там его выступлений по
поводу свободного софта что-то не видно. Или рассказ о том, что некий
филиал Гринпис в юго-восточной Азии перешёл на GNU/Linux - это и есть
экземпляр именно таких его выступлений? Что жы вы так плохо изучили
домашнюю страницу своего кумира или где, по вашему, тот самый раздел
"политические выступления" находится?
Разумеется понятие "политика" может включать в себя, как подмножество,
и понятие "идеология", однако не всякая идеология является частью
какой-то политики. Вот и вами любимый RMS избрал более подходящее
слово: "philosophy".

> > ICC является платформо-специализированым компилятором, поэтому
> > его использование на данной платформе имеет неоспоримые
> > преимущества по сравнению с обычным компилятором.
>
> Я то же самое говорил ранее. Я совершенно не против того, чтобы
> частные лица использовали какой угодно компилятор для компиляции
> ядра. Да хоть секретный компилятор ФСБ (если таковой имеется - но
> не в этом суть). Но _официальная_ ориентация на несвободные
> компиляторы политически неправильна.

И снова политика! Прямо обсуждение роли ЦК КПСС в сельском хозяйстве.
Откуда вообще у вас взялась ориентация на какой-то компилятор если
я уже который раз говорю о стандарте, его соблюдении и неправильности
ориентации на какой-то конкретный компилятор или тип компиляторов?
Правильная ориентация, при программировании, - это ориентация по
стандарту.

P.S. сейчас кто-то прочтёт про ориентацию и всё опошлит :-))

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Посмотрите и вы, предлагаю словарь lingvo.yandex.ru и в поле ввода введите словосочетание "most common".

Ну набрал. Он нашёл только "Of the two spellings, the former is more common." И как это относится к обсуждаемому словосочетанию? Заметьте, что один из вариантов перевода слова "common" - общепринятый, распространённый. Варианта "приемлимый" я не нашёл.

Раздел J.5 стандарта прямо говорит: "The following extensions are widely used in many systems". То есть, он описывает _существующие_ и _распространённые_ расширения языка Си. Поэтому высказывание про журнал или книжку для начинающих остаётся на вашей совести.

Заметьте, что ключевого слова asm в списке ключевых слов (раздел 6.4.1) _вообще_ нет. Опять таки, введение в J.5 говорит, что "The inclusion of any extension that may cause a strictly conforming program to become invalid renders an implementation nonconforming". То есть, все компиляторы, как угодно реализующие слово asm, если его нельзя отключить, являются не соответствующими стандарту.

В начале стандарта ясно сказано, что приложение "J" имеет _информативный_ характер.

> А что вы хотели сказать фразой "кодифицировать имеющуюся практику"?

Прямой перевод из "Rationale for International Standard - Programming Languages - C" (стр 3): "Codify existing practice to address evident deficients. Only those concepts, that have some prior art should be accepted"

Продолжение следует... tilde

anonymous ()

Re: Linus ЯНЦКЮЯЕМ НРЙЮГЮРЭЯЪ НР GCC ОПХ ОНЪБКЕМХХ АШЯРПНЦН Х ЛЮКЕМЭЙНЦН C ЙНЛОХКЪРНПЮ.

> > оНЯЛНРПХРЕ Х БШ, ОПЕДКЮЦЮЧ ЯКНБЮПЭ lingvo.yandex.ru Х Б ОНКЕ
> > ББНДЮ ББЕДХРЕ ЯКНБНЯНВЕРЮМХЕ "most common".
>
> мС МЮАПЮК. нМ МЮЬ?К РНКЭЙН "Of the two spellings, the former is
> more common." х ЙЮЙ ЩРН НРМНЯХРЯЪ Й НАЯСФДЮЕЛНЛС ЯКНБНЯНВЕРЮМХЧ?
> гЮЛЕРЭРЕ, ВРН НДХМ ХГ БЮПХЮМРНБ ОЕПЕБНДЮ ЯКНБЮ "common" -
> НАЫЕОПХМЪРШИ, ПЮЯОПНЯРПЮМ?ММШИ. бЮПХЮМРЮ "ОПХЕЛКХЛШИ" Ъ МЕ МЮЬ?К.

бШ, ХГБХМХРЕ, ЙНЦДЮ ОНЯКЕДМХИ ПЮГ ГПЕМХЕ ОПНБЕПЪКХ? бНР НРПШБНЙ РНЦН,
ВРН БХФС Ъ, ОПХ ОЕПЕБНДЕ "most common":

Of the two spellings, the former is more common. ≈ хГ ДБСУ БЮПХЮМРНБ
МЮОХЯЮМХЪ ОЕПБШИ ЪБКЪЕРЯЪ АНКЕЕ ОПХЕЛКЕЛШЛ.

еЯКХ БШДЕКЕМШЕ кХМЦБНИ "more common" == "АНКЕЕ ОПХЕЛКЕЛШИ", РН БОНКМЕ
ГЮЙНММН Х "most common" == "МЮХАНКЕЕ ОПХЕЛКЕЛШИ" ХКХ ДЮФЕ: "АНКЕЕ
БЯЕЦН ОПХЕЛКЕЛШИ".

> пЮГДЕК J.5 ЯРЮМДЮПРЮ ОПЪЛН ЦНБНПХР: "The following extensions are
> widely used in many systems". рН ЕЯРЭ, НМ НОХЯШБЮЕР _ЯСЫЕЯРБСЧЫХЕ_
> Х _ПЮЯОПНЯРПЮМ?ММШЕ_ ПЮЯЬХПЕМХЪ ЪГШЙЮ яХ. оНЩРНЛС БШЯЙЮГШБЮМХЕ ОПН
> ФСПМЮК ХКХ ЙМХФЙС ДКЪ МЮВХМЮЧЫХУ НЯРЮ?РЯЪ МЮ БЮЬЕИ ЯНБЕЯРХ.

мС ПЮГСЛЕЕРЯЪ, ВХРЮРЕКЪЛ ЯРЮМДЮПРЮ НВЕМЭ ХМРЕПЕЯМН, ЙЮЙХЕ АШКХ
ЯСЫЕЯРБСЧЫХЕ Х ПЮЯОПНЯРПЮМ?ММШЕ ПЮЯЬХПЕМХЪ ЪГШЙЮ C МЮ ЛНЛЕМР ОПХМЪРХЪ
ЩРНЦН ЯЮЛНЦН ЯРЮМДЮПРЮ. оПНЯРН ХЯРНПХВЕЯЙХИ ПНЛЮМ ЙЮЙНИ-РН, Ю МЕ
НТХЖХЮКЭМШИ ДНЙСЛЕМР ОПХГБЮМШИ ВРН-РН ЯРЮМДЮПРХГХПНБЮРЭ. еЫ? ПЮГ
ОНБРНПЪЧ, ЯРЮМДЮПР НОХЯШБЮЕР НАЪГЮРЕКЭМШЕ Х МЕНАЪГЮРЕКЭМШЕ ЩКЕЛЕМРШ
ЪГШЙЮ. мЕНАЪГЮРЕКЭМШЕ ЩКЕЛЕМРШ МЮГШБЮЧРЯЪ ПЮЯЬХПЕМХЪЛХ. оНЯЙНКЭЙН
ХЯОНКЭГНБЮМХЕ МЕНАЪГЮРЕКЭМШУ ЩКЕЛЕМРНБ БЕД?Р Й ОНРЕПЕ ОНПРЮАЕКЭМНЯРХ,
ЩРХ МЕНАЪГЮРЕКЭМШЕ ЩКЕЛЕМРШ МЕ ПЕЙНЛЕМДСЧРЯЪ, УНРЪ Х МЕ ГЮОПЕЫЮЧРЯЪ.
нМХ _ЯРЮМДЮПРХГХПСЕРЯЪ_. мЮОПХЛЕП ЙКЧВЕБНЕ ЯКНБН asm. нОХЯШБЮЕРЯЪ
РНКЭЙН НДХМ ЕЦН БЮПХЮМР, РНР ЙНРНПШИ ДЕЙКЮПХПСЕРЯЪ ЯРЮМДЮПРМШЛ.
бЮПХЮМР asm НР Borland ЪБКЪЕРЯЪ ЯСЫЕЯРБСЧЫХЛ Х ДНЯРЮРНВМН
ПЮЯОПНЯРПЮМ?ММШЛ, НДМЮЙН НМ РЮЛ МЕ СОНЛХМЮЕРЯЪ. мЕСФЕКХ БЮЛ РЮЙ РПСДМН
БЯ? ЩРН СБХДЕРЭ? х ГЮВЕЛ БШ НОЪРЭ НАПЕГЮЕРЕ ОПЕДКНФЕМХЕ? рЮЛ БЕДЭ
МЮОХЯЮМН: "The following extensions are widely used in many systems,
but are not portable to all implementations". рНЕЯРЭ БЮЛ ЦНБНПЪР, ВРН
МЕЯЛНРПЪ МЮ РН, ВРН ЩРХ ПЮЯЬХПЕМХЪ ЬХПНЙН ХЯОНКЭГСЧРЯЪ НМХ, НДМЮЙН,
МЕ ЯНБЛЕЯРХЛШ ЛЕФДС ЯНАНИ. бНР Я ЩРНИ МЕЯНБЛЕЯРХЛНЯРЭЧ _ПЕЮКХГЮЖХИ_
ЯРЮМДЮПР Х ОШРЮЕРЯЪ АНПНРЭЯЪ.

> гЮЛЕРЭРЕ, ВРН ЙКЧВЕБНЦН ЯКНБЮ asm Б ЯОХЯЙЕ ЙКЧВЕБШУ ЯКНБ (ПЮГДЕК
> 6.4.1) _БННАЫЕ_ МЕР. нОЪРЭ РЮЙХ, ББЕДЕМХЕ Б J.5 ЦНБНПХР, ВРН "The
> inclusion of any extension that may cause a strictly conforming
> program to become invalid renders an implementation nonconforming".
> рН ЕЯРЭ, БЯЕ ЙНЛОХКЪРНПШ, ЙЮЙ СЦНДМН ПЕЮКХГСЧЫХЕ ЯКНБН asm, ЕЯКХ
> ЕЦН МЕКЭГЪ НРЙКЧВХРЭ, ЪБКЪЧРЯЪ МЕ ЯННРБЕРЯРБСЧЫХЛХ ЯРЮМДЮПРС.

йКЧВЕБНЕ ЯКНБН asm МЕ ЪБКЪЕРЯЪ НАЪГЮРЕКЭМШЛ, ОНЩРНЛС ЕЦН МЕР Б РНЛ
ЯОХЯЙЕ. ю БНР Б ЯРЮМДЮПРЕ C++ ЩРН ЙКЧВЕБНЕ ЯКНБН ЯРЮМНБХРЯЪ
НАЪГЮРЕКЭМШЛ Х ОНЩРНЛС ОНЪБКЪЕРЯЪ Б ЯННРБЕРЯРБСЧЫЕЛ ЯОХЯЙЕ ЯБНЕЦН
ЯРЮМДЮПРЮ. оН ОНБНДС ОПЕДКНФЕМХЪ ХГ J.5. мС ОПНВРХРЕ БЕЯЭ J.5 ЖЕКХЙНЛ.
оЕПБНЕ ОПЕДКНФЕМХЕ Ъ ПЮГАХПЮК БШЬЕ, БРНПНЕ, ЙНРНПНЕ БШ ОПХБНДХРЕ РСР,
ОПНДНКФЮЕР ЛШЯКЭ МЮВЮРСЧ ОЕПБШЛ. б М?Л ПЮЯЯЙЮГШБЮЕРЯЪ, Й ВЕЛС ОПХБНДХР
НРЯСРЯРБХЕ ОНПРЮАХКЭМНЯРХ Б ПЕЮКХГЮЖХЪУ МЕНАЪГЮРЕКЭМШУ ПЮЯЬХПЕМХИ.
бЯЕ ЙНЛОХКЪРНПШ, МЕ ПЕЮКХГСЧЫХЕ ЙКЧВЕБНЕ ЯКНБН asm ХКХ ПЕЮКХГСЧЫХЕ ЕЦН
РЮЙ, ЙЮЙ НОХЯЮМН Б ЯРЮМДЮПРЕ ЯННРБЕРЯРБСЧР ЯРЮМДЮПРС. рЕ ЙНЛОХКЪРНПШ,
ЙНРНПШЕ ПЕЮКХГСЧР ЙКЧВЕБНЕ ЯКНБН asm, МН МЕ РЮЙ, ЙЮЙ НОХЯЮМН Б
ЯРЮМДЮПРЕ, ЩРНЛС ЯРЮМДЮПРС МЕ ЯННРБЕЯРЯБСЕР.

> б МЮВЮКЕ ЯРЮМДЮПРЮ ЪЯМН ЯЙЮГЮМН, ВРН ОПХКНФЕМХЕ "J" ХЛЕЕР
> _ХМТНПЛЮРХБМШИ_ УЮПЮЙРЕП.

хМТНПЛЮРХБМШИ УЮПЮЙРЕП ХЛЕЧР БЯ? ОПХКНФЕМХЪ, ЙНРНПШУ БЯЕЦН ДЕЯЪРЭ, МС
Х ВРН ЩРН МЮЛ ДНКФМН ЦНБНПХРЭ?

> > ю ВРН БШ УНРЕКХ ЯЙЮГЮРЭ ТПЮГНИ "ЙНДХТХЖХПНБЮРЭ ХЛЕЧЫСЧЯЪ
> > ОПЮЙРХЙС"?
>
> оПЪЛНИ ОЕПЕБНД ХГ "Rationale for International Standard -
> Programming Languages - C" (ЯРП 3): "Codify existing practice to
> address evident deficients. Only those concepts, that have some
> prior art should be accepted"

йЮЙ ЦНБНПХРЯЪ, ВРНА БПЮЦХ МЕ ДНЦЮДЮКХЯЭ, МН ГЮОСРЮКХЯЭ. вРН БШ
ОНМХЛЮЕРЕ ОНД ЙНДХТХЙЮЖХЕИ ХЛЕЧЫЕИЯЪ ОПЮЙРХЙХ? оНДЯЙЮГЙЮ, ЯКНБН
"ЙНДХТХЙЮЖХЪ" ОПНХЯУНДХР НР ЯКНБЮ "ЙНДЕЙЯ".

> оПНДНКФЕМХЕ ЯКЕДСЕР... tilde

дЮ СФ, Х ЦПЪМСК ЛЮПЬ...

anonymous ()

Re: Linus ЯНЦКЮЯЕМ НРЙЮГЮРЭЯЪ НР GCC ОПХ ОНЪБКЕМХХ АШЯРПНЦН Х ЛЮКЕМЭЙНЦН C ЙНЛОХКЪРНПЮ.

> > оНЯЛНРПХРЕ Х БШ, ОПЕДКЮЦЮЧ ЯКНБЮПЭ lingvo.yandex.ru Х Б ОНКЕ
> > ББНДЮ ББЕДХРЕ ЯКНБНЯНВЕРЮМХЕ "most common".
>
> мС МЮАПЮК. нМ МЮЬ?К РНКЭЙН "Of the two spellings, the former is
> more common." х ЙЮЙ ЩРН НРМНЯХРЯЪ Й НАЯСФДЮЕЛНЛС ЯКНБНЯНВЕРЮМХЧ?
> гЮЛЕРЭРЕ, ВРН НДХМ ХГ БЮПХЮМРНБ ОЕПЕБНДЮ ЯКНБЮ "common" -
> НАЫЕОПХМЪРШИ, ПЮЯОПНЯРПЮМ?ММШИ. бЮПХЮМРЮ "ОПХЕЛКХЛШИ" Ъ МЕ МЮЬ?К.

бШ, ХГБХМХРЕ, ЙНЦДЮ ОНЯКЕДМХИ ПЮГ ГПЕМХЕ ОПНБЕПЪКХ? бНР НРПШБНЙ РНЦН,
ВРН БХФС Ъ, ОПХ ОЕПЕБНДЕ "most common":

Of the two spellings, the former is more common. ≈ хГ ДБСУ БЮПХЮМРНБ
МЮОХЯЮМХЪ ОЕПБШИ ЪБКЪЕРЯЪ АНКЕЕ ОПХЕЛКЕЛШЛ.

еЯКХ БШДЕКЕМШЕ кХМЦБНИ "more common" == "АНКЕЕ ОПХЕЛКЕЛШИ", РН БОНКМЕ
ГЮЙНММН Х "most common" == "МЮХАНКЕЕ ОПХЕЛКЕЛШИ" ХКХ ДЮФЕ: "АНКЕЕ
БЯЕЦН ОПХЕЛКЕЛШИ".

> пЮГДЕК J.5 ЯРЮМДЮПРЮ ОПЪЛН ЦНБНПХР: "The following extensions are
> widely used in many systems". рН ЕЯРЭ, НМ НОХЯШБЮЕР _ЯСЫЕЯРБСЧЫХЕ_
> Х _ПЮЯОПНЯРПЮМ?ММШЕ_ ПЮЯЬХПЕМХЪ ЪГШЙЮ яХ. оНЩРНЛС БШЯЙЮГШБЮМХЕ ОПН
> ФСПМЮК ХКХ ЙМХФЙС ДКЪ МЮВХМЮЧЫХУ НЯРЮ?РЯЪ МЮ БЮЬЕИ ЯНБЕЯРХ.

мС ПЮГСЛЕЕРЯЪ, ВХРЮРЕКЪЛ ЯРЮМДЮПРЮ НВЕМЭ ХМРЕПЕЯМН, ЙЮЙХЕ АШКХ
ЯСЫЕЯРБСЧЫХЕ Х ПЮЯОПНЯРПЮМ?ММШЕ ПЮЯЬХПЕМХЪ ЪГШЙЮ C МЮ ЛНЛЕМР ОПХМЪРХЪ
ЩРНЦН ЯЮЛНЦН ЯРЮМДЮПРЮ. оПНЯРН ХЯРНПХВЕЯЙХИ ПНЛЮМ ЙЮЙНИ-РН, Ю МЕ
НТХЖХЮКЭМШИ ДНЙСЛЕМР ОПХГБЮМШИ ВРН-РН ЯРЮМДЮПРХГХПНБЮРЭ. еЫ? ПЮГ
ОНБРНПЪЧ, ЯРЮМДЮПР НОХЯШБЮЕР НАЪГЮРЕКЭМШЕ Х МЕНАЪГЮРЕКЭМШЕ ЩКЕЛЕМРШ
ЪГШЙЮ. мЕНАЪГЮРЕКЭМШЕ ЩКЕЛЕМРШ МЮГШБЮЧРЯЪ ПЮЯЬХПЕМХЪЛХ. оНЯЙНКЭЙН
ХЯОНКЭГНБЮМХЕ МЕНАЪГЮРЕКЭМШУ ЩКЕЛЕМРНБ БЕД?Р Й ОНРЕПЕ ОНПРЮАЕКЭМНЯРХ,
ЩРХ МЕНАЪГЮРЕКЭМШЕ ЩКЕЛЕМРШ МЕ ПЕЙНЛЕМДСЧРЯЪ, УНРЪ Х МЕ ГЮОПЕЫЮЧРЯЪ.
нМХ _ЯРЮМДЮПРХГХПСЕРЯЪ_. мЮОПХЛЕП ЙКЧВЕБНЕ ЯКНБН asm. нОХЯШБЮЕРЯЪ
РНКЭЙН НДХМ ЕЦН БЮПХЮМР, РНР ЙНРНПШИ ДЕЙКЮПХПСЕРЯЪ ЯРЮМДЮПРМШЛ.
бЮПХЮМР asm НР Borland ЪБКЪЕРЯЪ ЯСЫЕЯРБСЧЫХЛ Х ДНЯРЮРНВМН
ПЮЯОПНЯРПЮМ?ММШЛ, НДМЮЙН НМ РЮЛ МЕ СОНЛХМЮЕРЯЪ. мЕСФЕКХ БЮЛ РЮЙ РПСДМН
БЯ? ЩРН СБХДЕРЭ? х ГЮВЕЛ БШ НОЪРЭ НАПЕГЮЕРЕ ОПЕДКНФЕМХЕ? рЮЛ БЕДЭ
МЮОХЯЮМН: "The following extensions are widely used in many systems,
but are not portable to all implementations". рНЕЯРЭ БЮЛ ЦНБНПЪР, ВРН
МЕЯЛНРПЪ МЮ РН, ВРН ЩРХ ПЮЯЬХПЕМХЪ ЬХПНЙН ХЯОНКЭГСЧРЯЪ НМХ, НДМЮЙН,
МЕ ЯНБЛЕЯРХЛШ ЛЕФДС ЯНАНИ. бНР Я ЩРНИ МЕЯНБЛЕЯРХЛНЯРЭЧ _ПЕЮКХГЮЖХИ_
ЯРЮМДЮПР Х ОШРЮЕРЯЪ АНПНРЭЯЪ.

> гЮЛЕРЭРЕ, ВРН ЙКЧВЕБНЦН ЯКНБЮ asm Б ЯОХЯЙЕ ЙКЧВЕБШУ ЯКНБ (ПЮГДЕК
> 6.4.1) _БННАЫЕ_ МЕР. нОЪРЭ РЮЙХ, ББЕДЕМХЕ Б J.5 ЦНБНПХР, ВРН "The
> inclusion of any extension that may cause a strictly conforming
> program to become invalid renders an implementation nonconforming".
> рН ЕЯРЭ, БЯЕ ЙНЛОХКЪРНПШ, ЙЮЙ СЦНДМН ПЕЮКХГСЧЫХЕ ЯКНБН asm, ЕЯКХ
> ЕЦН МЕКЭГЪ НРЙКЧВХРЭ, ЪБКЪЧРЯЪ МЕ ЯННРБЕРЯРБСЧЫХЛХ ЯРЮМДЮПРС.

йКЧВЕБНЕ ЯКНБН asm МЕ ЪБКЪЕРЯЪ НАЪГЮРЕКЭМШЛ, ОНЩРНЛС ЕЦН МЕР Б РНЛ
ЯОХЯЙЕ. ю БНР Б ЯРЮМДЮПРЕ C++ ЩРН ЙКЧВЕБНЕ ЯКНБН ЯРЮМНБХРЯЪ
НАЪГЮРЕКЭМШЛ Х ОНЩРНЛС ОНЪБКЪЕРЯЪ Б ЯННРБЕРЯРБСЧЫЕЛ ЯОХЯЙЕ ЯБНЕЦН
ЯРЮМДЮПРЮ. оН ОНБНДС ОПЕДКНФЕМХЪ ХГ J.5. мС ОПНВРХРЕ БЕЯЭ J.5 ЖЕКХЙНЛ.
оЕПБНЕ ОПЕДКНФЕМХЕ Ъ ПЮГАХПЮК БШЬЕ, БРНПНЕ, ЙНРНПНЕ БШ ОПХБНДХРЕ РСР,
ОПНДНКФЮЕР ЛШЯКЭ МЮВЮРСЧ ОЕПБШЛ. б М?Л ПЮЯЯЙЮГШБЮЕРЯЪ, Й ВЕЛС ОПХБНДХР
НРЯСРЯРБХЕ ОНПРЮАХКЭМНЯРХ Б ПЕЮКХГЮЖХЪУ МЕНАЪГЮРЕКЭМШУ ПЮЯЬХПЕМХИ.
бЯЕ ЙНЛОХКЪРНПШ, МЕ ПЕЮКХГСЧЫХЕ ЙКЧВЕБНЕ ЯКНБН asm ХКХ ПЕЮКХГСЧЫХЕ ЕЦН
РЮЙ, ЙЮЙ НОХЯЮМН Б ЯРЮМДЮПРЕ ЯННРБЕРЯРБСЧР ЯРЮМДЮПРС. рЕ ЙНЛОХКЪРНПШ,
ЙНРНПШЕ ПЕЮКХГСЧР ЙКЧВЕБНЕ ЯКНБН asm, МН МЕ РЮЙ, ЙЮЙ НОХЯЮМН Б
ЯРЮМДЮПРЕ, ЩРНЛС ЯРЮМДЮПРС МЕ ЯННРБЕЯРЯБСЕР.

> б МЮВЮКЕ ЯРЮМДЮПРЮ ЪЯМН ЯЙЮГЮМН, ВРН ОПХКНФЕМХЕ "J" ХЛЕЕР
> _ХМТНПЛЮРХБМШИ_ УЮПЮЙРЕП.

хМТНПЛЮРХБМШИ УЮПЮЙРЕП ХЛЕЧР БЯ? ОПХКНФЕМХЪ, ЙНРНПШУ БЯЕЦН ДЕЯЪРЭ, МС
Х ВРН ЩРН МЮЛ ДНКФМН ЦНБНПХРЭ?

> > ю ВРН БШ УНРЕКХ ЯЙЮГЮРЭ ТПЮГНИ "ЙНДХТХЖХПНБЮРЭ ХЛЕЧЫСЧЯЪ
> > ОПЮЙРХЙС"?
>
> оПЪЛНИ ОЕПЕБНД ХГ "Rationale for International Standard -
> Programming Languages - C" (ЯРП 3): "Codify existing practice to
> address evident deficients. Only those concepts, that have some
> prior art should be accepted"

йЮЙ ЦНБНПХРЯЪ, ВРНА БПЮЦХ МЕ ДНЦЮДЮКХЯЭ, МН ГЮОСРЮКХЯЭ. вРН БШ
ОНМХЛЮЕРЕ ОНД ЙНДХТХЙЮЖХЕИ ХЛЕЧЫЕИЯЪ ОПЮЙРХЙХ? оНДЯЙЮГЙЮ, ЯКНБН
"ЙНДХТХЙЮЖХЪ" ОПНХЯУНДХР НР ЯКНБЮ "ЙНДЕЙЯ".

> оПНДНКФЕМХЕ ЯКЕДСЕР... tilde

дЮ СФ, Х ЦПЪМСК ЛЮПЬ...

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> > Посмотрите и вы, предлагаю словарь lingvo.yandex.ru и в поле
> > ввода введите словосочетание "most common".
>
> Ну набрал. Он наш?л только "Of the two spellings, the former is
> more common." И как это относится к обсуждаемому словосочетанию?
> Заметьте, что один из вариантов перевода слова "common" -
> общепринятый, распростран?нный. Варианта "приемлимый" я не наш?л.

Вы, извините, когда последний раз зрение проверяли? Вот отрывок того,
что вижу я, при переводе "most common":

Of the two spellings, the former is more common. &#8212; Из двух вариантов
написания первый является более приемлемым.

Если выделеные Лингвой "more common" == "более приемлемый", то вполне
законно и "most common" == "наиболее приемлемый" или даже: "более
всего приемлемый".

> Раздел J.5 стандарта прямо говорит: "The following extensions are
> widely used in many systems". То есть, он описывает _существующие_
> и _распростран?нные_ расширения языка Си. Поэтому высказывание про
> журнал или книжку для начинающих оста?тся на вашей совести.

Ну разумеется, читателям стандарта очень интересно, какие были
существующие и распростран?нные расширения языка C на момент принятия
этого самого стандарта. Просто исторический роман какой-то, а не
официальный документ призваный что-то стандартизировать. Ещ? раз
повторяю, стандарт описывает обязательные и необязательные элементы
языка. Необязательные элементы называются расширениями. Посколько
использование необязательных элементов вед?т к потере портабельности,
эти необязательные элементы не рекомендуются, хотя и не запрещаются.
Они _стандартизируется_. Например ключевое слово asm. Описывается
только один его вариант, тот который декларируется стандартным.
Вариант asm от Borland является существующим и достаточно
распростран?нным, однако он там не упоминается. Неужели вам так трудно
вс? это увидеть? И зачем вы опять обрезаете предложение? Там ведь
написано: "The following extensions are widely used in many systems,
but are not portable to all implementations". Тоесть вам говорят, что
несмотря на то, что эти расширения широко используются они, однако,
не совместимы между собой. Вот с этой несовместимостью _реализаций_
стандарт и пытается бороться.

> Заметьте, что ключевого слова asm в списке ключевых слов (раздел
> 6.4.1) _вообще_ нет. Опять таки, введение в J.5 говорит, что "The
> inclusion of any extension that may cause a strictly conforming
> program to become invalid renders an implementation nonconforming".
> То есть, все компиляторы, как угодно реализующие слово asm, если
> его нельзя отключить, являются не соответствующими стандарту.

Ключевое слово asm не является обязательным, поэтому его нет в том
списке. А вот в стандарте C++ это ключевое слово становится
обязательным и поэтому появляется в соответствующем списке своего
стандарта. По поводу предложения из J.5. Ну прочтите весь J.5 целиком.
Первое предложение я разбирал выше, второе, которое вы приводите тут,
продолжает мысль начатую первым. В н?м рассказывается, к чему приводит
отсутствие портабильности в реализациях необязательных расширений.
Все компиляторы, не реализующие ключевое слово asm или реализующие его
так, как описано в стандарте соответствуют стандарту. Те компиляторы,
которые реализуют ключевое слово asm, но не так, как описано в
стандарте, этому стандарту не соотвестсвует.

> В начале стандарта ясно сказано, что приложение "J" имеет
> _информативный_ характер.

Информативный характер имеют вс? приложения, которых всего десять, ну
и что это нам должно говорить?

> > А что вы хотели сказать фразой "кодифицировать имеющуюся
> > практику"?
>
> Прямой перевод из "Rationale for International Standard -
> Programming Languages - C" (стр 3): "Codify existing practice to
> address evident deficients. Only those concepts, that have some
> prior art should be accepted"

Как говорится, чтоб враги не догадались, но запутались. Что вы
понимаете под кодификацией имеющейся практики? Подсказка, слово
"кодификация" происходит от слова "кодекс".

> Продолжение следует... tilde

Да уж, и грянул марш...

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> Если выделеные Лингвой "more common" == "более приемлемый", то вполне законно и "most common" == "наиболее приемлемый" или даже: "более всего приемлемый".

Слово "common" в обсуждаемом фрагменте - прилагательное. Варианты его перевода меняются от того, с каким существительным оно употребляется. Для этого достаточно посмотреть словарную статью "common". Поэтому перевод слова "common" в отрыве от контекста не имеет смысла, а Вы именно так и поступаете. Вы вырвали одно значение из контекста примера и утверждаете об его универсальной применимости.

> Ну разумеется, читателям стандарта очень интересно, какие были существующие и распростран?нные расширения языка C на момент принятия этого самого стандарта.

Сарказм оставьте себе. Тем более, что Ваше прочтение буквой стандарта не подтверждается. А в остальном у Вас чистая демагогия. Ещё раз повторю: приложение J является _информационным_, а не нормативным.

> Ключевое слово asm не является обязательным, поэтому его нет в том списке.

Ключевое слово не может быть "необязательным". Оно либо есть, либо нет. В стандарте его нет. Следовательно, я могу свободно использовать asm в качестве имени идентификатора, и любая реализация, которая откажется из-за этого мою программу компилировать, будет _не соответствующей_ стандарту. Именно в этом смысл появления ключей выбора диалекта языка в GNU C.

> А вот в стандарте C++ это ключевое слово становится обязательным и поэтому появляется в соответствующем списке своего стандарта.

Ещё раз: причём здесь C++? Да там такое слово есть. Ну и что? В языке Си такого ключевого слова НЕТ!

> Информативный характер имеют вс? приложения, которых всего десять, ну и что это нам должно говорить?

Неправда Ваша. Читайте "Foreword, xiii". Там написано, что приложения D и F - нормативные.

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

> > Если выделеные Лингвой "more common" == "более приемлемый", то
> > вполне законно и "most common" == "наиболее приемлемый" или даже:
> > "более всего приемлемый".
>
> Слово "common" в обсуждаемом фрагменте - прилагательное. Варианты
> его перевода меняются от того, с каким существительным оно
> употребляется. Для этого достаточно посмотреть словарную
> статью "common". Поэтому перевод слова "common" в отрыве от
> контекста не имеет смысла, а Вы именно так и поступаете. Вы вырвали
> одно значение из контекста примера и утверждаете об его
> универсальной применимости.

Слово "common" в обоих фрагментах - прилагательное. Вариантов его
перевода на практике больше чем в соответствующей статье словаря.
Тот же Lingvo не имеет в статье "common" упоминания значения
"приемлимый". Это ничего не доказывает. Я увидел, что по смыслу
значение "распространённый" не вполне подходит. Также я увидел, что
значение "приемлимый" существует и принял его как наиболее подходящее
по смыслу. Ещё про смысл смотрите ниже:

> > Ну разумеется, читателям стандарта очень интересно, какие были
> > существующие и распространённые расширения языка C на момент
> > принятия этого самого стандарта.
>
> Сарказм оставьте себе. Тем более, что Ваше прочтение буквой
> стандарта не подтверждается. А в остальном у Вас чистая демагогия.
> Ещё раз повторю: приложение J является _информационным_, а не
> нормативным.

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

> > Ключевое слово asm не является обязательным, поэтому его нет в
> > том списке.
>
> Ключевое слово не может быть "необязательным". Оно либо есть, либо
> нет. В стандарте его нет. Следовательно, я могу свободно
> использовать asm в качестве имени идентификатора, и любая
> реализация, которая откажется из-за этого мою программу
> компилировать, будет _не соответствующей_ стандарту. Именно в этом
> смысл появления ключей выбора диалекта языка в GNU C.

В тексте стандарта ключевое слово asm как раз есть. Посколько это
ключевое слово необязательно, любой компилятор (заявленый как
соответствующий стандарту) может, либо иметь, либо не иметь
реализацию этого ключевого слова. Очевидно, что во втором случае
такой компилятор должен давать возможность отключать резервирование
необязательного ключевого слова. Таким образом C программы не
использующие asm и использующие asm, в соответствии со стандартом,
будут соответствовать стандарту (снова вышел каламбур). Также вполне
логично, что программа использующая стандартные, но тем не менее
необязательные расширения не обязательно должа компилироваться всеми
стандартными компиляторами.

> > А вот в стандарте C++ это ключевое слово становится обязательным
> > и поэтому появляется в соответствующем списке своего стандарта.
>
> Ещё раз: причём здесь C++? Да там такое слово есть. Ну и что?
> В языке Си такого ключевого слова НЕТ!

Оно там (в C) может быть, а может не быть, всё зависит от компилятора.
Кстати, могу предположить причину такой необязательности. Иногда
ассемблер для какой-то платформы недоступен. Например в своё время
фирма Inmos выпускала транспьютеры T414, T424 и T800. Ассемблер и
полная информация о их системе команд были недоступны. Вместо этого
Inmos распространяла свои системы с компилятором языка Occam.
В подобных случаях реализация ключевого слова asm в C компиляторе
становится невозможной. Вполне возможно, что и в 1999-ом году такие
системы существовали. C++ имеет несколько иное применение, нежели C,
видимо поэтому в его стандарте asm сделали обязательным.
Почему вообще я заговорил о стандарте C++ я уже объяснял.

> > Информативный характер имеют вс? приложения, которых всего
> > десять, ну и что это нам должно говорить?
>
> Неправда Ваша. Читайте "Foreword, xiii". Там написано, что
> приложения D и F - нормативные.

Да, поторопился немного. Однако это мало что меняет. Восемь из десяти
приложений информативны, а два остальных нормативны, посколько
пересказывают другие стандарты и разъясняют их связь с C. Какой же
смысл вы вкладываете в слово "информативный"?
Неужели научно-развлекательный?

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Блин, ну о чем вы спорите? Common в значении "приемлимый" не употребляется. Там фраза какая была? "Of the two spellings, the former is more common." Здесь речь идет о вариантах написания какого-то слова, и естественно что более приемлимым вариантом является тот, который более _распространен_, поэтому так и перевели. В случае со стандартом такой перевод не подходит. "Учитесь переводить по смыслу и со смыслом" (c) Один из анонимусов ;))

AL

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Da, kruto muzhiki szepilis... :)))

anonymous ()

Re: Linus согласен отказаться от GCC при появлении быстрого и маленького C компилятора.

Да, мужики, крючкотворцы вы знатные. Небось, начами работаете?

scum ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.