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

[Lethargeek]

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

а такой?

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

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

[Advertiser]

[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 !!!/

[b2m]

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

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

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

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

[Patron]

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

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

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

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

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

[b2m]

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

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

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

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

[Patron]

Legacy-команды могут следовать вперемешку с другими командами.

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

[Lethargeek]

Легаси-команды - это точно такие же 32-разрядные команды, как и все остальные 32-разрядные команды.

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

[Lethargeek]

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

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

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

Поясни. Вот раньше был массив, к примеру, из 5 слов, в 16-битном режиме располагались в памяти друг за другом. А как будут в 32-битном располагаться?

[Patron]

Вот раньше был массив, к примеру, из 5 слов, в 16-битном режиме располагались в памяти друг за другом. А как будут в 32-битном располагаться?

Другой пример - вот раньше был массив, к примеру, из 5 байтов, в 16-битном режиме располагались в памяти друг за другом. А как будут в 32-битном располагаться?

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

А как адресуются байты при выполнении следующего кода:

	MOVB	(R0)+,(R1)+
	MOVB	(R0)+,(R1)+
	MOVB	(R0)+,(R1)+
	MOVB	(R0)+,(R1)+
	MOVB	(R0)+,(R1)+

Процессор читает с шины двойные слова и потом как-то внутри себя выковыривает из прочитанного отдельные байты. Но ведь байты не только читать, но и писать нужно. А как PDP-11 может писать отдельные байты при 16-разрядной шине - так и при 32-разрядной сможет.

[Patron]

В ПРИНЦИПЕ возможна

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

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

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

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