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

[svinka]

разработка эффективного оптимизирующего кросс-компилятора C++ для PDP-11

что это за Юникс которому С++ нужен?

[Hunta]

что это за Юникс которому С++ нужен?

Правильный вариант фразы - Это программисты такие, которым С++ нужен.

[Patron]

что это за Юникс которому С++ нужен?

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

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

Для примера - небольшая программа на C++ и результат её компиляции:

extern "C" unsigned int Swab_r16( unsigned int x )
{
    return (x << 8)|(x >> 8);
}

	.text
	.globl	Swab_r16                ; -- Begin function Swab_r16
Swab_r16:                               ; @Swab_r16
; BB#0:
	SwaB	R0
	Return
                                        ; -- End function

	.section	".note.GNU-stack","",@progbits

[AlexG]

Хммм...
"Для примера - небольшая программа на C++ и результат её компиляции:"
Чем будет отличаться от эквивалентной "C"-программы ? При идентичных опциях компиляции и в этом же компиляторе но только с-режиме.
Можете привести результат компиляции ?

[Patron]

При идентичных опциях компиляции и в этом же компиляторе но только с-режиме.

Никогда не запускал CLang в C-режиме (можете это сделать с приведённым исходником самостоятельно), но подозреваю, что с точки зрения стандарта C исходник может быть синтаксически некорректным. Собственно потому (главным образом) я и использую для C-программирования только C++, что там более адекватный (на мой взгляд) синтаксис, чем в нативном C.

Можете привести результат компиляции ?

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

[AlexG]

Ок. Я не хочу "Святойвойны", но данный пример не говорит о тех или иных преимуществах с++ относительно С.
тк компиляция сего кода может быть идентична до "запятой". в частности openwatcom создаёт один и тот же исполняемый код.
ИМНО использовать С++, утверждая что он создаёт более оптимизированный код , чем просто С, не есть правильно.
Собственно "extern "C" говорит что "компилятор должен" компилировать сей текст как "язык С".
Другими словами Вы говорите что пишете на С++, а по факту пишете на чистом С.
И это как то не вяжется с утверждением " но С++ без использования классов и прочих "апгрейдов" при равной эффективности настолько удобнее просто C, что все C-программы я пишу только на C++"
ПС: Конечно в других частях программы Вы возможно и используете особенности языка С++, но приведённый пример явно не удачен для "демонстрации" плюсов языка С++.
Мож я что то не так понял ?

[Advertiser]

[Patron]

Мож я что то не так понял ?

Результат компиляции получается одинаковым. Удобство C++ в синтаксисе, который лично мне нравится больше. Ну и возможность задавать в C++ дефолтные значения для полей динамически создаваемых структур - тоже радует.

[bigral]

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

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

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

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

[Hunta]

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

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

[svinka]

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

Шанс есть!

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

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