32-разрядный процессор, полностью совместимый с архитектурой PDP-11.

[Patron]

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

Если речь идёт о компиляции Unix для машин с 64К ОЗУ, где борьба идёт за каждый байт - имеющиеся (для PDP-11) компиляторы C практически непригодны, потому что оптимизируют код очень слабо. Главная (по количеству бездарно потраченных компилятором байтов) проблема - наличие у функций прологов и эпилогов, а также использование стека для передачи параметров и создания локальных переменных. LLVM позволяет выделить пул временных регистров ( например для PDP11 - R0, R1, R2 ) и тогда первые три параметра вызова функции будут передаваться не в стеке, а в этих регистрах. Если же параметров у функции меньше (или их вообще нет) - свободные временные регистры будут автоматически использоваться для хранения локальных переменных. Когда исходник состоит из большого количества небольших функций с малым числом параметров - даже такая простенькая оптимизация сокращает объём генерируемого кода чуть ли не вдвое.

Проще говоря - есть реальный шанс сделать компилятор, который для базового ядра Unix уменьшит объём генерируемого кода в разы (по сравнению с изначальным).

[AlexG]

не большой оффтоп:
openwatcom также поступает: по максимуму использует регистры для передачи параметров, а что не помещается то идет через стек. Докучи это "поведение" компилятора можно "переопределить". Жалко что он только для интел и поверпс

[Hunta]

"Многие спрашивали, Windows написана на C или C++. Ответ такой: несмотря на объектно-ориентированный дизайн NT, как и большинство ОС, Windows почти полностью написана на C! Почему? Потому что C++ увеличивает потребление памяти и привносит накладные расходы на выполнение кода. Даже сегодня скрытые затраты на выполнение кода C++ могут удивить, но ещё в 1990-х, когда память стоила около $60/МБ (да… $60 за МЕГАБАЙТ!), скрытые затраты на vtables и прочее были значительными. Кроме того, затраты на косвенное обращение к виртуальным методам и разыменование объектов в то время могли привести к очень значительным потерям производительности и масштабированию кода C++"

[xolod]

Насколько мне известно, ядро и системные библиотеки всех широко распространенных ОС написаны на С. Linux, *BSD, Windows, MacOSX. Во многом из-за того, что у них у всех в разностепени, но корни идут от UNIXa Кернигана и Ричи.

[Hunta]

У Windows корни не из Unix-а - от слова совсем

[CodeMaster]

У Windows корни не из Unix-а - от слова совсем

Ну, как бы да:

Для разработки ОС NT фирма Microsoft пригласила группу специалистов из компании DEC во главе с Дэвидом Катлером, обладающую опытом создания многозадачных операционных систем, таких как VAX/VMS и RSX-11. Некоторое сходство, отмеченное между внутренними архитектурами Windows NT и ОС семейства VMS, дало основания обвинить вновь принятых сотрудников Microsoft в краже интеллектуальной собственности DEC.

Но и они же наверняка не C++ писаны. Ещё одной причиной почему Windows NT на С возможно является это:

Переносимость NT была одной из её первоочередных задач ... В качестве ОС высокой переносимости при разработке NT были взяты за пример ОС Unix и Mach.

Вряд ли тогда существовали надёжные и проверенные компиляторы C++ под все интересующие платформы.

[Hunta]

Вряд ли тогда существовали надёжные и проверенные компиляторы C++ под все интересующие платформы.

Наверняка. Но приведённая мной цитата - от сотрудника MS. В статье (она про новую версию cmd.exe и инфраструктуру консольных приложений) ещё говорится о том, что сейчас они постепенно переписывают код под C++ - но потому, что стоимость этого варианта (по ресурсам) стала ниже, чем во времена началаписания windows.

Учитывая количество доступных ресурсов на процах семейства PDP-11 - врят ли писание на C++ сильно взлетит. А С - он вообще делался с прицелом и на основе PDP-11, так что можно считать (классические компиляторы) своеобразным макро-ассемблерами.

Мне приходилось восстанавливать текст С-шных модулей из объектных - я после компиляции полученного текста на С получал такой же объектный файл - с точностью до бита.

[Patron]

Почему C-подмножество C++ это "С здорового человека" - небольшой пример.

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

На С++ есть два варианта решения задачи: 1) добавить вторую функцию, принимающую числовой аргумент; 2) модифицировать исходную функцию, добавив числовой аргумент со значением по умолчанию 1.

void LF( int n = 1 ) { while(n--) printf "\012"; }

На C второй вариант точно не прокатит - в стандарте C дефолтные значения параметров вызова не предусмотрены.

[Hunta]

Почему C-подмножество C++ это "С здорового человека" - небольшой пример

Потому что есть фундаментальные свойства языка, а есть синтаксический сахар. Дефолтные значения - пример синтаксического сахара.
И если добавить такие конструкции (удобства) в С - С++ окажется в ещё большем проигрыше.

[Patron]

И если добавить такие конструкции (удобства) в С - С++ окажется в ещё большем проигрыше.

О каком "проигрыше" речь, когда исходники обоих стандартов компилирует один и тот же компилятор, создающий из обоих вариантов один и тот же код, а разница только в удобстве синтаксиса у варианта C++.

C-подмножество C++ - это и есть то самое добавление нормальной функциональности в кривоногий синтаксис ванильного C, без которого о нормальном программировании говорить сложно.

Но помимо этого - при C-программировании на C++, появляется возможность использовать и некоторые простые "плюсы" расширенного стандарта. Хороший пример - задание начальных значений полей структур.

Вариант ванильного C:

struct s {
    int one;
    int two;
};

struct s *pS1 = (struct s*) malloc( sizeof(s) );
(*pS1).one = 1;
(*pS1).two = 2;

struct s *pS2 = (struct s*) malloc( sizeof(s) );
(*pS2).one = 1;
(*pS2).two = 2;

Вариант здорового C ( т.е. C++ ):

struct s {
    int one;
    int two;
 
   s(): one(1), two(2) {}
};

struct s *pS1 = new s;
struct s *pS2 = new s;