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

[bigral]

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

что-то мне помнится что это всего лишь указывает компилеру что ненадо извращать имена функций в результирующем obj как это принято делать в c++ и используется это исключительно для того чтоб obj генеренный "С" компилятором мог вызвать эту функцию без изменения в исходнике на "С" имени вызываемой функции по извращенческой схеме принятой в с++

- - - Добавлено - - -

про llvm интересно, на сколько я понимаю для написания крутого оптимизатора нужно четко представлять какие операции возможны в исполнителе для которого этот оптимизатор пишется... а так как llvm писался с учетом 32bit процессоров (да еще и не конкретного проца типа "cyrix 486sx25 rev32.22") то он оптимизирует с использованием каких-то общих для всех 32bit cpu операций а потому будет всегда отставать от таких компилеров типа open watcom. Но еще интереснее дело обстоит с pdp-11 учитывая что он довольно сильно отличается от "среднего 32bit" процессора... неужели есть шанс сделать лучше оптимизацию чем в древнем компиляторе на котором unix и был изначально скомпилен?

[Advertiser]

[Hunta]

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

Единственный шанс сделать лучшую оптимизацию - проанализировать, на какие низкоуровневые (для языка) но всё ещё высокоуровневые (для процессора) операции можно странслировать исходный код - а потом оптимизировать ПРОЦЕССОР под эти операции Насколько я себе представляю, по этому пошли разработчики (группа под руководством Вирта) процессора для рабочей станции Lilith и разработчики (наши) процессора Кронос

[svinka]

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

Шанс есть!

Видел года 2 назад порты шланга под 16-ти битные процы. Можно погуглить
clang msp430
:-) clang DCPU-16
8bit clang avr

а чем gcc не устраивает?

[Patron]

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

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

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

[AlexG]

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