OSDev

Ясно. А я уж и поробовал bochs.exe архиватором сжать - а он почти не сжимается - и хотел написать, типа сжатие не в счёт :-)

Оно всё равно в счёт, правда, неясно, в какую сторону. Как в счёт и формат файлов. Сравнивать надо всё ж по размерам секций кода, а не по файлам. Например, перемещаемый COFF займёт явно больше места, чем абсолютно тот же код, но в виде неперемещаемого бинарника, но, понятно, к эффективности транслятора это ни малейшего отношения иметь не будет.

Лучше сравнивать по секциям кода и данных вместе, т.к. различные статики и структурные метаданные программы могут оказаться как в коде, так и в данных - это ни как не регламентировано.

Касательно проекта bochs, ни какой статической линковки системных библиотек там нет, только что проверил. Там статические библиотеки создаются из собственных подпроектов, и это всё пользовательский код, который относится к основному функционалу, а не рантайму.
Да, там как-бы статически линкуются системные библиотеки, но по факту они являются стабами к dll-кам. Так устроены все программы.

Вот виндовый:


MSVCRT или более новый аналог где? Не верю, что bochs не использует функции сишной либы.

Вот размер:


Вот линуксовый:


Здесь видно, что сборка из рпм использует системную глибц.

Размер:

Часть этих функций в VC имеют атрибут intrinsic (тоесть встраиваемые), а часть из них отсутствует в VC, потому что являются POSIX функциями. Видимо, часть функций вызывается не прользовательским кодом, а рантаймом компилятора.
В целом, статик не статик, а это внутренние проблемы VC. Так что GCC впереди :-)

Соглашусь что GCC создает более раздутый код чем Keil, но! При оптимизации по размеру код у GCC может быть меньше и быстрее, это под ARM Cortex-M3. Причем код заметно быстрее работает, чем меня GCC приятно удивил В моем проекте переносного цифрового осцилла с выводом на ЖК TFT, Keil с макс. оптимизацией O3(по скорости) выдавал ~55кадров/сек., GCC же при O0 ~67, при Os ~85-90! И код получается по размеру чуть больше чем у Keil с O3 по размеру(скорость работы при этом в минусе полном 30-35 кадров). Это все на ЖК 240х400 и STM32F103, так что не все так плохо как тут пишут
Но соглашусь что при работе с регистрами напрямую GCC может лажать, очень неприятный момент когда нужно работать с мелкими МК, так как приходится использовать библиотеки от ST(с ними 100% работает корректно), это конечно же расстраивает
Все описанное относится к arm-none-eabi-gcc 4.6 который я использовал совместно с CooCox CoIDE.

А в целом хорошо что существуют альтернативы платным компиляторам, спасибо сообществу за GCC! Не всем по карману Keil/IAR/Atollic и т.д. особенно для личных проектов.