Применение специальных возможностей GCC в ядре Linux

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

нестандартным возможностям - НЕТ

В мемориз, однозначно

да-да-да.... интересная статья.

С99 хорош, и расширения GNU99 тоже.

> нестандартным возможностям - НЕТ

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

+0.9

(все-таки ядра это специальная вестч, а в большинстве применений действительно по рукам за такое надо давать)

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

Ванильное ядро спокойно и без проблем компилируется icc, что в очередной раз доказывает

> нестандартным возможностям - НЕТ

в прикладном программировании - поддерживаю. в системном - к сожалению, это неизбежность

>нестандартным возможностям - НЕТ

Домострой и первобытно-общинный строй

Есть, конечно, полезное вроде интервалов для case, но вот обилие всяких likely/unlikely только добавляет лишние сущности для восприятия, т.е. отвлекает

> нестандартным возможностям - НЕТ

+1

То, что майкрософт видите ли в MSVC расширяет стандарт - это отстой. А то, что GCC вводит ни с кем несовместимые расширения - это крутизна? Linux-way так сказать.

К тому же, GCC не истина в последней инстанции, и у меня может возникнуть потребность скомпилировать Linux kernel чем-нибудь ещё.

>нестандартным возможностям - НЕТ

Как только микрософт, так сразу можно и за ним

s/ссылатся/ссылаться/ s/вы также можете использовать их в ваших приложениях./вы также можете использовать их в своих приложениях./

а какие ещё потребности у тебя могут возникнуть?

детский сад.

Интересные, однако, вещи. За отсутствие некоторых из них я в своё время сильно ругался на Си. Кстати, там вроде ничего не было про возможность объявлять вложенные функции. Выяснено опытным путём, работает)

> обилие всяких likely/unlikely только добавляет лишние сущности

хз.

мне вот нравится злопотреблять likely/unlikely. и вовсе не для
оптимизации, скорее, для меня это форма документации.

Это всё уже давно известно и лежит на http://www.opennet.ru/docs/RUS/gcc/gcc1-4.html

И при чём тут Linux вообще?

> скорее, для меня это форма документации

Кто-то запрещает писать комментарии?

likly/unlikely если не гцц, можно задефайнить а ля
#define likely(x) x
и не волноваться. В ядре такая оптимизация - хорошо.

Про интервалы не знал.

> В ядре такая оптимизация - хорошо.

Чем она - "хорошо"? Без нее ядро не успевает обрабатывать прерывания? Без нее ядро кушает 90% процессорного времени? Нафига она там?

крууто! и наконец полезная статья от ибм))

> То, что майкрософт видите ли в MSVC расширяет стандарт - это отстой. А то, что GCC вводит ни с кем несовместимые расширения - это крутизна? Linux-way так сказать.

Толсто. MS C компиллер для каких платформ доступен? Насколько он открыт? Для каких платформ он может код генерировать? Догадаешься с какой целью им такие несовместимости нужны?

> К тому же, GCC не истина в последней инстанции

А если учесть поддерживаемые платформы и открытость - то получается, что истина в последней инстанции. Подобные расширения в системном программировании нужны. И GCC расширения - гораздо меньшее зло, нежели MS. К тому же код, с умеренным использованием gnu99 сановским С компилятором у меня собирался. Если бы не собрался - поставил бы gcc и собрал.

> Кто-то запрещает писать комментарии?

вопрос, надо понимать, риторический. на всякий
случай, likely/unlikely тоже никто не запрещает
писать.

я и комментарии пишу, но неохотно. ибо ленив
и английский знаю плохо.

собственно, все что я хотел сказать, это то,
что не все разделяют мнение о том, что эти
hints делают код менее читабельным.

>у меня может возникнуть потребность скомпилировать Linux kernel чем-нибудь ещё.

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

знал только про likely-unlikely

Отличная статья. Забукмаркил

Ну хоть кто-то решился потроллить немножко. Ка-ааайф.

>Чем она - "хорошо"? Без нее ядро не успевает обрабатывать прерывания? Без нее ядро кушает 90% процессорного времени? Нафига она там?

Без нее ядро не поспевает за моими мыслями.

Очень познавательно. Конечно, некоторые приемы часто используются тут и там и поэтому "на слуху", но вот я, к примеру, про __builtin_return_address() не знал. Автору спасибо.

> нестандартным возможностям - НЕТ

Смотря как они используются. В ядре делается компиляторозависимый хедер, в котором все __attribute__(()) дефайнятся как стандартные (в рамках ядра) макросы. При смене компилятора потребуется только заменить этот хедер.

А вот в майкрософте частенько код фигарят как есть, вместе с __typof, __guidof или что там ещё было. Ну хотя они и не претендуют на переносимость.

А какую документативность, так сказать, несет [un]likely?

> А какую документативность, так сказать, несет [un]likely?

Ну как, читаешь код, а там написано

if (likely(x)) do_thing();

Ага, значит автор предположил, что x редко бывает нулем.

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

> +0.9

> (все-таки ядра это специальная вестч, а в большинстве применений действительно по рукам за такое надо давать)

Вообще-то обычно это макросы и если gcc - используется расширение, если нет - не используется.

По рукам надо давать не тем кто использует, а тем кто не делает альтернативу без использования.

typeof() и интервалы case, на мой взгляд - вообще вещи достойны включения в следующую версию стандарта Си.

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

> Ванильное ядро спокойно и без проблем компилируется icc, что в очередной раз доказывает

С оптимизицией не выше О2

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

Пример ядрас Линукс. Зачем писать ядро так, чтобы его нельзя было скомпилить в опцией оптимизации выше О2? Получается, что gcc не может на полную катушку использовать весь свой потенциал оптимизации, зато программёры ядра создают "оптимизированый" код, который понимают ТОЛЬКО ОНИ.

Эо самое что ни на есть ущемление свободы ПО. Потому что навязываются стандарты программирования зависящие от конкретного компилятора и сужается круг программистов, которые могут понять код ядра.

Это что за ересь?

#define min(x, y) ({                            \
        typeof(x) _min1 = (x);                  \
        typeof(y) _min2 = (y);                  \
        (void) (&_min1 == &_min2);              \
        _min1 < _min2 ? _min1 : _min2; })

Зачем, собсногря, так много букав?

>Я принципиально против расширений

Чувак, напр. __attribute__((packed)) иногда *нужен*. Для всяких структур, которые потом пойдут к процессору с помощью какой-нибудь необычной команды ассемблера.

>нестандартным возможностям - НЕТ

Вам тогда в netbsd...

Клоуны как всегда жгут :)))

Ашшо один клоун :)

Курни таки исходники ядра (в статье указано место) и сделай свой compiler-xyz.h

> крууто! и наконец полезная статья от ибм))

+1 оба раза.

>>нестандартным возможностям - НЕТ >Вам тогда в netbsd...

Можно и не так жестоко :)

-pedantic или -ansi ;)

Еще одна полезная статья от IBM, так держать :)

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

При переходе с архитектуры на архитектуру ты раньше на misalignment и endianness срубишься, чем на т.н. "рюшечках gcc". И вообще, более "всеядного", в плане архитектур, компилятора на сегодняшний день просто не существует <trollmode>, так что остальные должны соответствовать или молчать в сторонке</trollmode>.

> GCC включает в себя поддержку интервалов, которые можно использовать во многих областях языка C

Что только не делают, лишь бы не использовать Аду :-)

Дельная статейка - уже в закладках.

P.S.

GCC для C:

static int sd_major(int major_idx)
{
	switch (major_idx) {
	case 0:
		return SCSI_DISK0_MAJOR;
	case 1 ... 7:
		return SCSI_DISK1_MAJOR + major_idx - 1;
	case 8 ... 15:
		return SCSI_DISK8_MAJOR + major_idx - 8;
	default:
		BUG();
		return 0;	/* shut up gcc */
	}
}

--------------------

Ада:

case Letter is
    when 'a'..'z'| 'A'..'Z' => Put ("letter");
    when '0'..'9'           => Put ("digit! Value is"); Put (letter);
    when ''' | '"' | '`'    => Put ("quote mark");
    when '&'                => Put ("ampersand");
    when others             => Put ("something else");
end case;

--------------------

GCC для C:

int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };

--------------------

Ада:

a: array(1..10) of integer := (1|10 => 100, 2..5 => 200, others => 300);