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

[Patron]

Насколько я знаю - стандартный линковщик ничего не знает.

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

[Hunta]

какой сделаем - такой и будет

Для начала нужно сделать процессор.

[Lethargeek]

Но в том и преимущество компоновщика, что он совершенно точно знает, где в линкуемых библиотеках 32-разрядный код, а где 16-разрядный. Поэтому, прилинковывая 16-разрядную подпрограмму к 32-разрядному коду - компоновщик может или перекомпилировать 16-разрядный код в ПРАВИЛЬНЫЙ 32-разрядный код,

как проверить ПРАВИЛЬНОСТЬ без изучения ассемблерного исходника? (что по трудоёмкости почти как переписать)

или оформить вызов 16-разрядной подпрограммы через системный вызов интерпретатора 16-разрядного кода.

да так любой 32-битный процессор с эмулятором pdp-11 можно представлять как "полностью совместимый"

[Patron]

как проверить ПРАВИЛЬНОСТЬ без изучения ассемблерного исходника?

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

да так любой 32-битный процессор с эмулятором pdp-11 можно представлять как "полностью совместимый"

Если работающая на неком процессоре операционная система позволяет запускать любые программы PDP-11 с точно таким же результатом, как на PDP-11, а архитектура позволяет подключать к шине любые устройства PDP-11, то так ли уж важно, что именно написано на процессоре.

[Lethargeek]

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

это между машинным дизассемблером и бинарником его нету, а между исходником и бинарником оно есть

Приведите пример 16-разрядного ассемблерного текста, по коду которого невозможно определить, к каким адресам и с каким размером операнда происходит обращение.

выше приводил уже, с пересылкой

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

это в принципе для многих случаев косвенного доступа невозможно или же технически затруднительно
(поди узнай, что окажется в рантайме в регистре адреса, и человек-то догадается не всегда)

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

склонен думать, что сомнительных моментов будет настолько много, что в итоге почти всё потребует эмулятора

Если работающая на неком процессоре операционная система позволяет запускать любые программы PDP-11 с точно таким же результатом, как на PDP-11, а архитектура позволяет подключать к шине любые устройства PDP-11, то так ли уж важно, что именно написано на процессоре.

тогда целью должен быть не процессор, а адаптер для подключения устройств pdp к нынешним пк

[Patron]

для многих случаев косвенного доступа невозможно или же технически затруднительно
(поди узнай, что окажется в рантайме в регистре адреса, и человек-то догадается не всегда)

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

тогда целью должен быть не процессор, а адаптер для подключения устройств pdp к нынешним пк

Отнюдь. Процессор может предоставлять эмулятору сервис ускорения эмуляции. Команда декодирования кода PDP-11 с переходом на обработчик из таблицы в аргументе, команда загрузки аргументов и команда выгрузки результата с базами источника и приёмника, команда исполнения кода PDP-11 с ведением флагов в ячейке эмуляции PSW и т.п. Именно такие архитектурные особенности делают 32-разрядный процессор более совместимым с 16-разрядным кодом PDP-11, который далеко не всегда может быть автоматически перекомпилирован для непосредственного исполнения в адресном пространстве 32-разрядного процесса, а значит - нуждается в эмуляции. Вводя специальные команды, позволяющие исполнить любую команду PDP-11 за 1-2 шага с использованием (например) специального режима виртуального мапинга памяти, для доступа к аргументам за пределами пространства вызываемого кода - мы получаем полностью контролируемую интеграцию 16-разрядного кода в 32-разрядный, лишь незначительно снижающую скорость исполнения.

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

Для примера - аппаратная виртуализация Intel позволяет программному эмулятору выполнять эмулируемый код Intel лишь на несколько процентов медленнее, чем при его прямом исполнении на процессоре. Такой подход к достижению совместимости 32-разрядного процессора с архитектурой PDP-11 выглядит вполне перспективным. Сейчас провёл эксперимент - когда я запускаю эмулятор процессора 1801ВМ2 на "железном" процессоре Intel - максимальное быстродействие получается 27.6 MIPS, а при запуске в программном эмуляторе процессора Intel, использующем технологию виртуализации - быстродействие снижается до 25.6 MIPS

[Advertiser]

[Hunta]

аппаратная виртуализация Intel позволяет программному эмулятору выполнять эмулируемый код

Там не программная эмуляция - там управляемый проброс ТОГО ЖЕ самого процессора внутрь виртуалки плюс возможности ограничения по функционалу. Никакой программной эмуляции и никакого расширений функционала. Именно поэтому - несколько процентов снижения быстродействия.

[blackmirror]

Patron, читаю уже 11ю страницу и никак не могу понять что в итоге вы хотите получить:
1) возможность запускать "правильные"(использующи� � только системные вызовы) 16 разрядные прикладные программы внутри 32х разрядной ОС
2) возможность запустить 16 разрядную ОС или новую 32х разрядную
3) возможность запустить 16 разрядную ОС внутри 32х разрядной
4) возможность запустить несколько 16 разрядных ОС внутри 32х разрядной
5) возможность запускать 16 разрядные ОС внутри 32х разрядных программ, внутри 32х разрядной ОС
?

[Hunta]

и никак не могу понять что в итоге вы хотите получить:

Про остальное ничего пока сказать не могу - это уже конкретика (причём конкретика одного блока проца) - и что бы ответить на неё - нужна архитектура в целом и ответ на вопрос - зачем (нам это может понадобиться)? А мы пока ещё далеко в самом начале проекта архитектуры.

Я не знаю, что хочет получить Патрон.

Что хочу получить я - проц, идеологически построенный по принципам (не обязательно всем, но хочу такую же вкусную ортогональную систему команд) моего любимого PDP-11, но без его недостатков, основной из которых - 16-ти битность. Сильно желательно поддержка PDP-11 совместимого режима работы, что бы можно было с минимальными переделками запустить на нём мою любимую же RSX-11M-PLUS (подозреваю так же, что и RT-11 можно будет запустить с минимальными переделками) - что бы с самого начала была доступна кака-никака операционка. Думаю, что после запуска этих операционок проги, которые не лезут напрямую к железу, тоже будут работать Наличие режима совместимости позволит так же собрать комп типа PDP-совместимых и при наличии соответствующего железа (типа КЦГД) (может быть в эмуляторе) и запускать проги типа игрушек.

Наличие (правильно спроектированного) 32-битного режима позволит (с бОльшими переделками) запустить RSX-11M-PLUS с большим объёмом ресурсов и создавать (более быстродействующие) программы менее гемморойным способом.

Для чего мне оно? А ни для чего - just for fun

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

И поскольку с моей точки зрения народ в этом топике начал не с того и пошёл не туда - я теперь слежу за ним только краем уха.

[Patron]

Patron, читаю уже 11ю страницу и никак не могу понять что в итоге вы хотите получить

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

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

Именно поэтому - несколько процентов снижения быстродействия.

Наличие в ядре 32-разрядного процессора декодера легаси-команд позволяет без больших накладных расходов использовать его для виртуализации PDP-11. Если (например) исполняется команда "вызвать 16-разрядный код", после которой регистры расширенного набора используются в качестве виртуального SP, а также в качестве сегментных для виртуального мапинга и для передачи процессору ссылки на блок контекста с начальным значением виртуального PSW и начальными значениями 16-разрядных R0..R5, а возврат в 32-разрядный режим происходит при передаче вызванным кодом управления за пределы текущего виртуального 16-разрядного сегмента кода ( при выполнении вызванным кодом команд RETURN, EMT и т.п. ). Можно иметь вариант вызова 16-разрядного кода, который использует текущие значения 32-разрядных R0..R5 и битов реального PSW в качестве начальных и возвращает результат в этих же регистрах ( понятно, что из виртуального 16-разрядного PSW в реальное 32-разрядное PSW при этом копируются только биты признаков ).

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

Сильно желательно поддержка PDP-11 совместимого режима работы

Нет смысла иметь в 32-разрядном процессоре отдельное 16-разрядное ядро для отдельного 16-разрядного режима работы. Гораздо проще иметь отдельный 16-разрядный сопроцессор, прошивку которого можно заливать индивидуально и который (благодаря специальному протоколу взаимодействия 32-разрядного процессора и 16-разрядного сопроцессора) подменяет на шине 32-разрядный процессор на время выполнения 16-разрядного кода.

Наличие (правильно спроектированного) 32-битного режима позволит

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


На мой взгляд - при нормальной виртуализации можно спокойно забыть об "аппаратном 16-разрядном режиме" и реализовывать любые "фантазии на тему PDP-11" в стандартном 32-разрядном режиме.