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

[Patron]

Не совсем всё понял, и не уверен, что означает "совместимый с архитектурой", но сможет ли старый код весь правильно работать с таким подходом?

Идея такая, что старый код должен работать в старых операционках ( ведь реальный старый код без системных вызовов не бывает ), поэтому для запуска старого кода предусмотрены специальные 16-разрядные процессы, выполняемые не на основном 32-разрядном ядре, а на специальном сопроцессоре, полностью имитирующем самую навороченную архитектуру PDP-11 с 8 Мб ОЗУ. Архитектура допускает создание любого количества 16-разрядных процессов с возможностью мапинга индивидуальных адресов эмулируемой страницы ввода-вывода каждого такого процесса на реальные адреса физического 32-разрядного пространства ввода-вывода. Понятно, что для запуска старого кода конкретной операционки - сначала в эмулируемой 22-разрядной архитектуре надо будет загрузить соответствующую операционку.

Большого практического смысла в этом нет, поэтому при отсутствии в конкретной реализации 22-разрядного сопроцессора - создание 16-разрядных процессов 32-разрядным процессором будет невозможно.

КМК легаси-команды вообще не должны бы видеть нечётные слова при выравнивании, и адреса для их пропуска следует транслировать дополнительно.

Легаси-команды - это полноценные 32-разрядные команды с нулевым старшим словом кода команды. Они нужны не для запуска старого двоичного 16-разрядного кода в 32-разрядных процессах, а для упрощения переделки кодогенераторов старых компиляторов. Чтобы старый ассемблерный текст, скомпилированный для 32-разрядной архитектуры, имел отличия в работе от работы на PDP-11 - нужно очень постараться. Что-то вроде: ADD #4,PC или MOV 2(SP),(SP) | RETURN - сработает по-разному ( и поэтому выдаст предупреждение при компиляции ), но команды не использующие явно PC и SP для косвенно-индексной адресации - сработают одинаково.

В принципе - Legacy и Extended Legacy команды ничем не лучше и не хуже аналогичных по функционалу Pure 32 команд, просто их реализация позволяет осуществлять разработку 32-разрядной архитектуры, максимально совместимой с PDP-11 - более плавно и последовательно. Кроме того - такая (например) легаси-команда, как HALT - вряд ли должна иметь отличающийся "новый" 32-разрядный код.

[Lethargeek]

ведь реальный старый код без системных вызовов не бывает

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

поэтому для запуска старого кода предусмотрены специальные 16-разрядные процессы, выполняемые не на основном 32-разрядном ядре, а на специальном сопроцессоре,

О какой тогда "полной совместимости" идёт речь? Я подумал, что планировалась бинарная.
А тут даже полная совместимость на уровне ассемблерных исходников под вопросом.

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

Не пойму, в чём уж такая проблема и зачем для её решения порождать/усугублять проблему несовместимости

Чтобы старый ассемблерный текст, скомпилированный для 32-разрядной архитектуры, имел отличия в работе от работы на PDP-11 - нужно очень постараться. Что-то вроде: ADD #4,PC или MOV 2(SP),(SP) | RETURN - сработает по-разному ( и поэтому выдаст предупреждение при компиляции ), но команды не использующие явно PC и SP для косвенно-индексной адресации - сработают одинаково.

Так что насчёт модифицируемого кода? Вот хотя бы перед вызовом в тело процедуры вписать константу. А потом чтоб тот же адрес в том же регистре послужил базой для доступа к таблице какой-нибудь (или же для вычисления базы). А как автоинкременты должны работать? Неизвестно же, это шаг на следующую команду или на данные.

[Patron]

О какой тогда "полной совместимости" идёт речь? Я подумал, что планировалась бинарная.

Бинарная совместимость обеспечивается в 16-разрядном режиме. В 32-разрядном режиме полная бинарная совместимость в принципе невозможна, а частичная имеется на уровне легаси-команд. Если загрузить слова 16-разрядного кода в каждое второе слово 32-разрядного процесса - этот код будет работать в 32-разрядном режиме, но без ГАРАНТИИ полной совместимости, которая абсолютно невозможна ни в теории, ни на практике.

Не пойму, в чём уж такая проблема и зачем для её решения порождать/усугублять проблему несовместимости

Проблема в том, что полная совместимость абсолютно невозможна, поэтому проблемы совместимости 16-разрядного кода и 32-разрядного кода в принципе не существует. 16-разрядный код должен исполняться в 16-разрядном режиме, а 32-разрядный код - в 32-разрядном режиме.

Так что насчёт модифицируемого кода? Вот хотя бы перед вызовом в тело процедуры вписать константу. А потом чтоб тот же адрес в том же регистре послужил базой для доступа к таблице какой-нибудь (или же для вычисления базы). А как автоинкременты должны работать? Неизвестно же, это шаг на следующую команду или на данные.

Названные проблемы на уровне ассемблерных исходников отсутствуют, поэтому если скомпилировать исходник в 16-разрядный код - он будет работать в 16-разрядном режиме, а если скомпилировать исходник в 32-разрядный код - он будет работать в 32-разрядном режиме. Приведите пример исходника с относительной адресацией без числовых констант, который будет работать в 16-разрядном режиме, но не будет работать в 32-разрядном режиме.

Такой код - в любом режиме будет работать одинаково:

	MOV	CONST, R0
	MOVB	ByteTBL(R0), R1
	MOV	#2, CONST
	MOV	(PC)+, R0
CONST:	1
	ADD	#WordTBL, R0
	MOV	(R0)+, R2
	MOV	(R0)+, R3
	HALT
ByteTBL:
	.BYTE	0,1,2,3,4,5,6,7
WordTBL:
	.WORD	0,1,2,3,4,5,6,7

[Lethargeek]

Такой код - в любом режиме будет работать одинаково: ...

а такой?

...
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
...

вот ЧТО здесь пересылается?

[b2m]

В 32-разрядном режиме полная бинарная совместимость в принципе невозможна, а частичная имеется на уровне легаси-команд.

А если сделать так: просто расширить регистры и шину адреса/данных до 32-х бит, а Legacy команды при записи будут выдавать ноль в старших 16 битах.

С точки зрения программиста это будет выглядеть так, как будто ОЗУ и ПЗУ теперь двухслойное, в первом слое хранятся 16-битные данные, во втором - дополнительные старшие 16 бит. Если второй слой содержит только нули, то будет выполняться 16-битная программа, но если там не нули, то это 32-х битные команды. Начальный загрузчик может загрузить либо 16-битный код (с размером слова 16 бит), либо 32-битный код. Сам загрузчик в ПЗУ должен быть конечно-же 32-х битным, чтобы иметь возможность писать старшие 16 бит (т.е. второй слой).

И кстати, можно в ПЗУ записать обычный 16-битный код в первый слой, а второй слой ПЗУ оставить нулевым. Тогда будет практически полностью 16-битная система (ну если не делать переход на неинициализированный участок ОЗУ), которая должна выполнять любой существующий на данный момент 16-битный код.

Минус лишь в том, что вроде бы процессор адресует 32-битные слова, но адрес слов увеличивается как обычно на 2, т.е. 0,2,4,6,...

[Patron]

вот ЧТО здесь пересылается?

Пересылаются одиночные слова ( 16-разрядные ) и регистры инкрементируются на 2. Чтобы пересылались двойные слова и регистры инкрементировались на 4 - у кода команды в старшем слове должен стоять бит "двусловного размера операндов". На каком основании компилятор решит ставить такой бит - зависит от разработчика компилятора. Вариантов множество - можно для пересылки двойного слова использовать название команды MOVD, можно для фрагмента кода задать режим компиляции "двусловный размер операндов для старых мнемоник" и т.д и т.п. Но если ничего не предпринимать - компилятор интерпретирует такие мнемоники как команды пересылки 16-разрядных слов.

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

А если сделать так: просто расширить регистры и шину адреса/данных до 32-х бит, а Legacy команды при записи будут выдавать ноль в старших 16 битах. С точки зрения программиста это будет выглядеть так, как будто ОЗУ и ПЗУ теперь двухслойное, в первом слое хранятся 16-битные данные, во втором - дополнительные старшие 16 бит. Если второй слой содержит только нули, то будет выполняться 16-битная программа, но если там не нули, то это 32-х битные команды.

Проблема в том, что архитектура допускает использование абсолютных адресов. При 32-разрядном абсолютном адресе - он содержит нули в старшем слове только для первых 64К адресов. А у нас код должен исполняться одинаково в любом месте адресного пространства.

Если первые 64К адресного пространства занимает область векторов, то как следующий код может не иметь битов ни в одном старшем слове:

	MOV	#MES, R0
	.PRINT
	HALT

MES:	.ASCIZ	/Hello from 32-bit address space !!!/

[Advertiser]

[b2m]

Если первые 64К адресного пространства занимает область векторов

Можно сделать и так, что при выполнении Legacy-команды старшие 16 бит регистра PC не будут модифицироваться, тогда можно под 16-битный процесс отводить любую страницу в 64Кб.

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

Так будет даже правильнее, когда Legacy-команды не трогают старшие 16 бит любых регистров.
При выполнении Legacy-команды точно также, как при записи старшие 16 бит шины данных содержат нули, старшие 16 бит адреса должны выдавать старшие биты регистра PC.

[Lethargeek]

Пересылаются одиночные слова ( 16-разрядные ) и регистры инкрементируется на 2.

Вот именно. Только вот какая незадача, по задумке автора 16-битного кода сей фрагмент мог из разных мест вызываться для разных действий, для пересылок как инструкций, так и слов данных. Или даже смешанного куска. Но в 32-битном режиме размер инструкций изменился, а данных - нет.

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

И кстати, можно в ПЗУ записать обычный 16-битный код в первый слой, а второй слой ПЗУ оставить нулевым. Тогда будет практически полностью 16-битная система (ну если не делать переход на неинициализированный участок ОЗУ), которая должна выполнять любой существующий на данный момент 16-битный код.

Как при этом данные адресуются?

[Patron]

тогда можно под 16-битный процесс отводить любую страницу в 64Кб.

Для 16-битных процессов в архитектуре есть специальный режим абсолютной совместимости с PDP-11, поэтому сейчас речь только о 32-битных процессах, в любом месте адресного пространства которых может исполняться легаси-код.

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

Вот именно. Только вот какая незадача, по задумке автора 16-битного кода сей фрагмент мог из разных мест вызываться для разных действий, для пересылок как инструкций, так и слов данных. Или даже смешанного куска. Но в 32-битном режиме размер инструкций изменился, а данных - нет.

Именно так, поэтому полная совместимость невозможна В ПРИНЦИПЕ.

[b2m]

Как при этом данные адресуются?

Также как и раньше. В том-то и идея, что нет разницы ни для 16-битного, ни для 32-битного кода.

Для 16-битных процессов в архитектуре есть специальный режим абсолютной совместимости с PDP-11

Я предлагаю отказаться от режимов. Legacy-команды могут следовать вперемешку с другими командами. Это упростит архитектуру процессора. Несложно будет переделать то, что отреверсили, и долнить это новыми командами.