Просмотр полной версии : 32-разрядный процессор, полностью совместимый с архитектурой PDP-11.
..
Не очень сложно написать эмулятор 32-разрядного процессора, полностью совместимого с архитектурой PDP-11, но сначала полезно понять, какой должна быть его архитектура.
Первое, что приходит в голову - 22-разрядная и 32-разрядная архитектуры памяти не должны пересекаться по масштабу, поэтому минимальный блок распределяемого 32-разрядного адресного пространства должен иметь размер 222 ( 4 Mb ), а значит - режимы доступа и другие атрибуты распределяемой памяти должны задаваться для регионов, состоящих из целого числа таких блоков. 16-разрядные регионы возможны двух типов - совмещённых программ и данных ( размером 1 блок ) и разделённых программ и данных ( размером 2 блока ). Размер создаваемого 16-разрядного региона автоматически задаёт его тип. 32-разрядные регионы могут быть только совмещённого типа, поэтому непосредственные данные 32-разрядного кода всегда находятся вперемешку с кодами команд.
Количество 16-разрядных регионов не ограничено, поэтому страница ввода/вывода каждого такого региона эмулируется процессором ( с возможностью мапить отдельные адреса ввода-вывода на совместимые устройства реальной 32-разрядной шины ).
Каждому 32-разрядному процессу выделяются все 232 байтов виртуальной памяти. Номер выполняемого процесса задаётся в PSW и называется "мода":
http://pic.pdp-11.ru/images/psw32a.png
Нулевой процесс имеет особые привилегии и выполняется в адресном пространстве KERNEL-моды. Максимальное число процессов составляет: 256*3 = 768 ( из-за недопустимости номера моды 2 - все 256 номеров, оканчивающихся на 2, выпадают ).
Процессор сохраняет/восстанавливает контекст при смене региона исполнения кода, поэтому только от операционной системы зависит, выполнять каждую программу в отдельной моде, выполнять все программы в различных регионах общей моды или использовать смешанную стратегию.
...
Первый 4Мб блок адресного пространства KERNEL-моды содержит вектора прерываний и начальный KERNEL-стек, последний 4Мб блок KERNEL-моды содержит блок ввода-вывода со стартовым ПЗУ и регистрами внешних устройств.
Относительно организации ввода-вывода в 32-разрядном режиме полной ясности нет. Возможно, оптимальным является вариант, когда при включении питания создаётся единственный одноблочный 4Мб регион ввода-вывода в конце адресного пространства, но впоследствии операционная система может создавать дополнительные регионы ввода-вывода произвольного размера ( кратного 4Мб ). Чтобы разделить на шине доступ к памяти и доступ к устройствам - шина должна иметь дополнительную линию ( фактически расширяющую непосредственно адресуемое пространство до 233 ).
...
При выполнении команд процессор предъявляет только одно требование к выравниванию кода - команды должны начинаться с чётных адресов. 16-разрядные команды могут содержать от 1 до 3 = 16-разрядных слов с одним словом кода команды, 32-разрядные - от 1 до 6 ( или более? ) 16-разрядных слов с одним или двумя словами кода команды.
Размер поля 32-разрядной команды увеличивается ( по сравнению с 16-разрядной командой ) с 3 до 4 битов, поэтому помимо регистров R0..R7 появляются ещё 8 регистров, назначение которых предстоит определить. Также появляются 7 дополнительных способов адресации ( каких? ). 8-й набор битов адресации ( например ^b1111 ) резервируется. В позиции источника ( т.е. для битов 15,14,13,12 ) такой набор является признаком отсутствия у кода команды второго слова. В результате - однословные команды имеют 15 вариантов с использованием младшего байта ( в качестве кода приёмника или байтовой константы ) и дополнительно - 256 вариантов однобайтовых команд.
Двухсловные команды могут задавать размер отдельно источника и приёмника в 1, 2 или 4 байта - для чего выделяются младшие 4 бита второго слова команды ( по два бита на размер источника и размер приёмника ). Поле позволяет задавать также размер источника и/или приёмника в 8 байтов, но в текущей реализации это недопустимо. Остаток даёт 4095 различных команд с источником и приёмником и дополнительно ( для кодов команд с единицей в старшем разряде второго слова ) - более 4000000 команд, не удовлетворяющих стандарту PDP-11 на кодирование источника и приёмника.
...
Относительно специального назначения дополнительных регистров процессора. Видится необходимым наличие регистра базы региона кода ( задающего постоянное смещение для PC ), регистра базы региона стека ( задающего постоянное смещение для SP ) и регистра базы региона данных ( задающего постоянное смещение для косвенной адресации обычных регистров ). База кода может изменяться только в KERNEL-моде, потому что её изменение приводит к переключению исполняемого потока, относительно порядка изменения базы стека ясности нет, а регистр базы региона данных - скорее всего может изменяться пользователем для доступа к собственному региону кода или стека, как к данным.
Если дополнительные способы адресации будут предусматривать использование индексных регистров - ещё два регистра надо отдать для индексного регистра источника и индексного регистра приёмника. Остаются три регистра - R8, R9, R10 ( или RA ? ), которые можно использовать как дополнительные регистры общего назначения. Если конкретная программа не использует индексную адресацию - индексные регистры также могут использоваться ею в качестве регистров общего назначения. При косвенной адресации относительно индексного регистра - регистр базы данных используется так же, как и при косвенной адресации относительно обычных регистров.
Регистры базы могут непосредственно использоваться в команде только с режимом адресации 00.
32-разрядный процессор, полностью совместимый с архитектурой PDP-11.
Теперь эмуляцию КЦГД точно не дождаться. :)
CodeMaster
31.08.2017, 16:57
Не очень сложно написать эмулятор 32-разрядного процессора, полностью совместимого с архитектурой PDP-11
А зачем? Не в смысле нафига козе баян, а какие плюшки и для чего это даст? Или просто чтоб было?
каким образом и какими средствами предполагается писать для него ПО?На первом этапе - только кросс-компиляция под Windows. Где-то ( если не ошибаюсь ) есть порт MACRO-11 на C++, поэтому его надо переделать на генерацию 32-разрядного кода PDP-11.
Если на первом этапе не торопиться с выдумыванием новых методов адресации и не использовать дополнительные регистры - тогда для написания 32-разрядного кода стартового ПЗУ, позволяющего создавать 16-разрядный регион и запускать в нём любую операционку PDP-11 - надо (в основном) определиться с механизмом управления регионами адресов и создать спецификацию RMU ( 32bit Region Menegment Unit ).
- - - Добавлено - - -
А зачем? Не в смысле нафига козе баян, а какие плюшки и для чего это даст? Или просто чтоб было?В железе такое могут реализовать только те, кому (по каким-то причинам) такое ОЧЕНЬ надо. Мне такое даром не надо. Однако, полезно максимально отчётливо представлять, как такое чудо могло бы выглядеть и работать. А когда максимально отчётливое представление есть - написать эмулятор можно за пару дней ( хотя мне такой эмулятор тоже даром не нужен ).
Возможность прямо указывать размер источника и приёмника порождает любопытные следствия:
1. Можно выбирать - расширять или нет знак передаваемого байта/слова, как при пересылке в регистр, так и при пересылке в память. Для пересылки без расширения знака нужно использовать одинаковый размер источника и приёмника ( MovB == MovBB ; MovW == MovWW ; MovD == MovDD ). При пересылке с "расширением данных" ( режимы BW, BD и WD ) - старшие байты приёмника заполняются знаком источника. Выравнивание проверяется отдельно для каждого операнда, поэтому у команд MovBW и MovBD - первый операнд ( байт == B ) не требует выравнивания, а второй ( слово == W или двойное слово == D ) должен быть выровнен по границе слова.
2. При источнике-регистре - запрещённые режимы "сжатия данных" WB, DB и DW могут использоваться для чтения старшего байта первого слова регистра ( при режиме WB ), старшего байта второго слова регистра ( при режиме DB ) или старшего слова регистра ( при режиме DW ).
А может для начала сделать макетик на 1839ВМ1 с СОЗУ вместо ПЗУ микрокоманд, для "тренировке на кошках" ?
*
Если для чистого новодела - целесообразно страничку BS7 оставить в неприкосновенности, 8 кбайт...
Биты моды фактически задают номер 32-разрядного раздела ( объёмом 4Гб ) в общем 42-разрядном адресном пространстве (объёмом 4Тб). Понятно, что столько физического ОЗУ вряд ли кто-то воткнёт, поэтому объём физически доступной виртуальной памяти ограничен только объёмом SSD своп-диска ( для которого 4Тб уже не фантастика ). Возможно, учитывая проблемы с запрещённым номером моды, есть смысл выделить всю моду супервизора в качестве 4Гб "страницы ввода-вывода". Тогда объём теоретически доступной виртуальной памяти сократится до 241 (максимальный объём своп-диска = 2Тб).
Поскольку операционная система ( живущая в KERNEL-моде ) должна загружать программы и данные в любую моду - очевидно, что система управления регионами должна позволять подключать регионы одной моды в другую. В такой ситуации логично предположить, что после включения питания - управление передаётся на адрес 0000 моды супервизора, где расположено стартовое ПЗУ, которое (в случае загрузки 32-разрядной операционной системы) - мапит младший 4Мб блок моды супервизора в одноблочный регион ввода-вывода в старших 4Мб KERNEL-моды.
А может для начала сделать макетик на 1839ВМ1 с СОЗУ вместо ПЗУ микрокоманд, для "тренировке на кошках" ?
*Если для чистого новодела - целесообразно страничку BS7 оставить в неприкосновенности, 8 кбайт...
Многие процессоры до их воплощения в железе были реализованны в софтовом виде (тот же pdp11/20 в желе имел дефекты и пришлось патчить софтовый эмуль на котором обкатывали первый софт для pdp11 пока самих железных pdp11/20 было всегото десяток). Без рабочей просчитанной софтовой модели вообще не стоит лезть в железо. И еще один момент, если модель показывает что тактов требуется на выполнение больше чем в ВМ3 то такой процессор никому не нужен, в новом процессоре все команды должны занимать меньше тактов чем в ВМ3. При первом переносе в "железо" логичнее использовать доступный 5v FPGA (acex ?) чем недоступный простым смертным советский 1839ВМ1.
По изложенному выше, можно только судить об крайней сырости идей по переделке j11 в такой себе "j11/32" (причем явно навевает аналогия с 8086->80286/386). Тут надо понимать что процессор должен проектироваться так чтобы работать с как можно меньшим реально доступным обьемом ОЗУ, при этом создавая для процессов ВСЕ режимы j11 + 32bit режим в котором можно использовать кроме всего того что есть в j11 еще и 32bit aдресацию!!! Довольно сложная задача создать такую модель. По поводу предложенного увиличения количества регистров: это сразу затормозит сохранение контекста вдвое...
И еще один момент, если модель показывает что тактов требуется на выполнение больше чем в ВМ3 то такой процессор никому не нужен, в новом процессоре все команды должны занимать меньше тактов чем в ВМ3
Это смотря какая тактовая
Это смотря какая тактовая
тактовая всегда максимально возможная для текущего уровня техпроцесса
Тут надо понимать что процессор должен проектироваться так чтобы работать с как можно меньшим реально доступным обьемом ОЗУВ предлагаемом варианте процессор после включения питания работает вообще без ОЗУ, для загрузки и работы 16-разрядной операционной системы требует от 4Мб до 8Мб ОЗУ, а для загрузки и работы 32-разрядной ОС - от 32Мб до 2Тб ОЗУ.
32bit режим в котором можно использовать кроме всего того что есть в j11 еще и 32bit aдресацию!!!Тащить старый MMU в 32-разрядный режим абсурдно - для мапинга 2Тб виртуальной памяти в [32Мб ОЗУ + своп-файл] нужен другой функционал.
...
В принципе - для лучшего использования физической памяти можно уменьшить размер "атома" виртуальной памяти с 4 Мб до 64Кб, что позволит создавать 16-разрядные регионы размером от 64Кб до 8Мб ( при разделении команд и данных ) и 32-разрядные регионы размером от 64Кб до 4Гб.
Тащить старый MMU в 32-разрядный режим абсурдно - для мапинга 2Тб виртуальной памяти в [32Мб ОЗУ + своп-файл] нужен другой функционал.
Несовместимый с j11 процессор уже никакой не pdp11 вообще, так что обсуждать его тут значит выходить за рамки темы.
работает вообще без ОЗУ, для загрузки и работы 16-разрядной операционной системы требует от 4Мб до 8Мб ОЗУ
Это звучит как оксиморон. Я о реальном мире говорю а не об академической теории. Например i386 требует минимальной памяти около 256...512кб (вектора прерывания + таблицы поддержки защищенного режима + код минимального OS + код задач (по сути части могут быть в swap) + код обслуживания прерывания + код драйвера внешнего диска для загрузки задач и свопа). Возможно ктото сможет все это дело ужать до 128кб но я очень сомневаюсь.
Несовместимый с j11 процессор уже никакой не pdp11 вообщеУ J11 нет 32-разрядного режима, поэтому любой процессор с 32-разрядным режимом не совместим с J11 в 32-разрядном режиме.
Речь лишь о том, чтобы 32-разрядный процессор был полностью совместим с PDP-11 в 16-разрядном режиме ( с 22-разрядной адресацией и разделением адресного пространства кода и данных ). Относительно 32-разрядного режима в принципе не может быть "критериев совместимости с PDP-11".
Вопрос - какой практический смысл в xMode?
Вопрос - какой практический смысл в xMode?Смысл в том, что реализация более чем одной 32-разрядной моды относительно несложна, а там где есть две моды - почему не быть остальным ( сколько влезет в PSW ).
Ведь виртуальная память и при одной моде нужна - нельзя же требовать, чтобы минимальный объём физической памяти был 4Гб. А при наличии механизма виртуальной памяти, мапящего блоки виртуальных адресов в относительно компактное ОЗУ и теоретически бесконечный своп-файл, расширить виртуальное адресное пространство дополнительными модами - практически ничего не стоит.
32-разрядный процессор работает с диспетчером виртуальной памяти через виртуальную ( или физическую, при реализации процессора на нескольких чипах ) 32-разрядную шину виртуальных адресов, а уже диспетчер виртуальной памяти работает с реальной физической памятью через внешнюю 42 разрядную шину. Поэтому физически, и при одной моде, и при сотнях мод - в реальном ОЗУ будут находиться только те блоки виртуальной памяти, к которым было обращение процессора, и разница лишь в том, что при работе в одной общей моде - в регистры базы кода, стека и данных надо каждый раз записывать конкретные значения активируемого процесса, а при работе в разных модах - регистр базы кода всегда нулевой, потому что каждому процессу выделяются все 4Гб 32-разрядных виртуальных адресов.
Когда процессы исполняются в общей моде - они имеют адресный доступ к пространствам друг-друга и только механизм управления доступом к регионам ( при правильной настройке ) не позволяет случиться страшному. Когда же процессы исполняются в разных модах - они для доступа к пространствам друг-друга (через общий регион) должны совершить значительное количество нетривиальных действий.
В ваших терминах на классическом PDP-11 всего три моды, одна из которых - пользовательская, что не мешает запускать теоретически любое количество процессов, память которых изолирована и которые не могут повредить друг дружке и ядру операционки.
а при работе в разных модах - регистр базы кода всегда нулевой, потому что каждому процессу выделяются все 4Гб 32-разрядных виртуальных адресов.
В ваших терминах - в PDP-11 используется всего одна мода для пользовательских процессов, что не мешает
каждому процессу выделяются все
выделить полные 64 кб
там где есть две моды - почему не быть остальным
Принцип - пусть будет, но для чего это пригодится - не понятно - плохой принцип.
Ещё раз вопрос - практический смысл в наличии не трёх, а большего количество мод.
Особенно учитывая, что у Вас идёт совмещение - старых двух бит из PSW, задающих режим работы процессора и непонятного xMode
Нулевой процесс имеет особые привилегии и выполняется в адресном пространстве KERNEL-моды
Нулевой процесс - этот тот, которые имеет xMode=0? А если в старых битах PSW для него стоит режим работы процессора 11 (то есть пользовательский) - это тогда как. А если (xMode=0, psw 00) и (xMode=0, psw=11) - тогда как - это разные процессы, это один процесс, если это один процесс - на что влияют биты в psw?
в PDP-11 используется всего одна мода для пользовательских процессов, что не мешает выделить полные 64 кбНо для этого надо вручную управлять диспетчером памяти, меняя мапинг USER-моды при каждой смене активного процесса. Если бы у разработчиков PDP11 было не по 2 бита на номер моды, а по 9 ( и диспетчер памяти имел не несколько единиц наборов регистров PAR, а несколько сотен ) - они вряд ли отказались бы от 512 мод вместо двух-трёх. Ведь тогда содержимое регистров PAR не надо изменять при переключении процессов и это ничего не стоит.
Конечно, можно вместо 512 наборов PAR использовать только два, но ЗАЧЕМ, если это ничего не стоит, тем более, что диспетчер виртуальной памяти может сам заполнять всё содержимое PAR, и лишь иногда процессор может изменять для некоторых страниц приоритет вытеснения в своп. Когда диспетчер памяти работает параллельно с процессором - общая работа идёт гораздо быстрее, для этого и нужны расширенные биты моды.
идёт совмещение - старых двух бит из PSW, задающих режим работы процессора и непонятного xModexMode - это старшие биты моды, дополнительно к "старым" битам моды из PSW. Если отдать всю моду супервизора под работу с устройствами - остаётся 9 битов моды ( старший бит моды "старого" PSW + 8 битов xMode ). У KERNEL-моды все биты моды нулевые.
- - - Добавлено - - -
если два бита моды "старого" PSW = 00 - номер моды определяется как [xMode*2 + 0]
если два бита моды "старого" PSW = 01 - значение xMode не учитывается и выбирается мода супервизора
если два бита моды "старого" PSW = 11 - номер моды определяется как [xMode*2 + 1]
При этом нулевая мода - это KERNEL-мода, а все остальные ( кроме моды супервизора ) - это USER-моды.
...
В принципе можно наплевать на запрещённую моду 16-разрядного режима, тогда номер моды будет иметь 10 битов:
если два бита моды "старого" PSW = 00 - номер моды определяется как [xMode*4 + 0]
если два бита моды "старого" PSW = 01 - и значение xMode == 00 - выбирается мода супервизора
если два бита моды "старого" PSW = 01 - и значение xMode != 00 - номер моды определяется как [xMode*4 + 1]
если два бита моды "старого" PSW = 10 - номер моды определяется как [xMode*4 + 2]
если два бита моды "старого" PSW = 11 - номер моды определяется как [xMode*4 + 3]
При этом нулевая мода - это KERNEL-мода, первая мода - мода супервизора, а все остальные - это USER-моды.
они вряд ли отказались бы от 512 мод вместо двух-трёх
Может да, а может нет.
Сколько потребуется регистров-описателей памяти? Если я не ошибаюсь, то при минимальной единицы 4 мб (22 бита) и общем адресном пространстве 42 бита количество адресуемых единиц 2 в 20 степени. Если идти по логике работы MMU PDP-11 - 2 в 20 степени регистров и если предположить регистр в 32 бита - то получается, один набор аналогов PAR - 4 мб (вроде не ошибся в вычислениях). Плюс 8+2=10 2 в 10 = 1024 - 256 = 768 - итого 3 гигабайта памяти на описание всех PAR. А в PDP-11 было два регистра - PAR и PDR (смещение и дескриптор) - итого 6 гигабайт памяти внутрь проца - если его делать железным.
И даже если это эмулятор - 6 гигов - только эта структура. Какой то толстый эмулятор получается.
А теперь другой вопрос - если у меня в систему запущено пара десятков процессов - нафига мне большая часть этих регистров описателей?
Напомнить, как пошла Интел в своём диспетчере памяти проца?
Сколько потребуется регистров-описателей памяти?Вряд ли есть смысл подходить к вопросу статически. Как внутри себя работает диспетчер памяти - это его проблема. Главное, чтобы он обеспечивал максимальное быстродействие при оптимальном использовании ресурсов. Сразу понятно, что диспетчеру памяти нет смысла описывать больше виртуальной памяти, чем размер ОЗУ + размер своп-файла. Если размер ОЗУ мал, а размер своп-файла большой - всё умрёт в свопе и никто не станет ругать диспетчер памяти, если он высвопит часть таблицы доступа. Когда ОЗУ некуда девать - никто не станет ругать диспетчер памяти, если он использует малую часть ОЗУ под таблицы доступа. Главное, чтобы всё происходило оптимальным образом - тогда итоговое быстродействие будет максимальным по сравнению с любым другим сценарием.
Не проще ли ограничиться DEC-16 бит и сделать просто надстройку для работы с 32-х битным котом ?
И , пожалуйста, сделайте полноценную МПИ 24-х бит адрес по ГОСТ. Разумеется, мультиплексировать А/Д не надо, можно ограничиться исходной ISA-16 ( или подобной ).
*
По поводу формата 32-бит инструктажа - целесообразно вынести этот вопрос в отдельный блок типа СОЗУ , для того, что бы каждый смог собрать свою кодировку инструкций. Да, понадобится изрядный массив СОЗУ - но в итоге будет "супер-универсальность".
, чтобы всё происходило оптимальным образом
если он использует малую часть ОЗУ под таблицы доступа
Ну то есть пока никакого понимания - как оно всё должно работать.
Помните, что компьютер - это дурак. Оно что то умеет делать (и его умений мало), но умеет это делать очень быстро. И если у человека в голове нет понимания того, как должна работать его программа (а внутренности проца - это тоже программа) - трудно ждать чего либо вменяемого от программы.
- - - Добавлено - - -
пожалуйста, сделайте полноценную МПИ 24-х бит адрес по ГОСТ
Смысл?
Не проще ли ограничиться DEC-16 бит и сделать просто надстройку для работы с 32-х битным кодом ?Народ хочет разврата ( 4Гб непрерывных адресов памяти вместо 64Кб ).
И, пожалуйста, сделайте полноценную МПИ 24-х бит адрес по ГОСТ.Быстрый 32-битный процессор не станет сам работать с медленной 5-вольтовой шиной - только через блок сопряжения.
Быстрый 32-битный процессор не станет сам работать с медленной 5-вольтовой шиной - только через блок сопряжения.
производители плат на 80386/80486 до этого как то не допёрли. Для сведения - VLB и PCI появились позже. А VLB сколько вольт была???
про 5вольт PCI на частоте 33МГц даже в Википедии написано
- - - Добавлено - - -
можно ограничиться исходной ISA-16
там 20 бит адреса
или подобной
Это какой?
Ну то есть пока никакого понимания - как оно всё должно работать.А какие у нас альтернативы.. Если взять за образец управление мапингом памяти в PDP-11, то там 64Кб адресного пространства разбиты на 1024 блока по 64 байта, доступные для выделения в виде 8 страниц размером от 64 байт до 8Кб каждая. В случае 32-битного адресного пространства объёмом 4Гб, разбитого на 1024 блока по 4Мб - доступные для выделения 8 страниц могут иметь размер от 4Мб до 512Мб каждая. Для хранения информации о 1024 модах потребуется 1024*8*2*2 = 32Кб PAR+PDR. Это при 16-разрядных регистрах. При 32-разрядных регистрах - адресуемое через них пространство возрастает с 38 бит до 54 бит. Если снизить разрядность адресации до 42 бит - размер блока памяти может быть уменьшен с 4Мб до 512 байт.
Проще говоря, переход в дековском MMU от 16-разрядных регистров к 32-разрядным - позволяет мапить в 42-битное физическое пространство 8 страниц размером от 512б до 512Мб с шагом 512б. Для хранения в MMU информации о 1024 модах потребуется 1024*8*4*2 = 64Кб PAR+PDR.
- - - Добавлено - - -
Однако, всего 8 страниц по 512 Мб - как-то слишком крупно. Если не обращаться к MMU при каждой смене активного процесса 1000 раз в секунду, а только загружать регистры моды один раз при загрузке процесса в моду, тогда и 8192 страницы с максимальным размером 512Кб - вполне терпимо. Для хранения в MMU информации о 1024 модах в таком случае потребуется 64Мб PAR+PDR.
CodeMaster
02.09.2017, 08:46
Это какой?
EISA?
А какие у нас альтернативы
Отказаться от понятия моды.
Вы пытаетесь за её счёт решить задачу неперезагрузки дескрипторов отображения памяти при смене контекста (при переключении между процессами). Я пока знаю только две альтернативы - или были придуманы два варианта - или мы экономим служебную (внутриMMU-шную, читай внутрикристальную память) за счёт использования оперативной (и кто то должен загружать дескрипторы - или проц или MMU) или у нас есть (определённый) объём служебной с возможностью первоначальной загрузки и редкой перезагрузкой при переключении контекста.
Первый сценарий в комбинации со вторым используют современные процы Intel (насколько я в курсе - процом создаётся дескриптор, адрес которого загружается в спец регистр MMU и содержимое которого MMU потом кеширует у себя внутри, что бы не лазить каждый раз в медленное озу, а при переключении контекста загружается адрес нового дескриптора и т.д.).
Второй сценарий - в чистом виде - PDP-11 с возможностью неперезагрузки дескрипторов MMU при переключении между тремя контекстами (или режимами работы проца или модами - назовите как хотите)
Первый сценарий замедляет переключение контекста при экономии служебных (быстрых?) ОЗУ
Второй ускоряет переключение контекста при повышенных расходах служебных (быстрых?) ОЗУ - насколько повышенных - зависит от того сколько аппаратных описаний контекстов собрались реализовать.
С моей точки зрения, продуманности подхода в предлагаемой модели проца - нет.
Ещё один момент - микропрограммирование (именно классическое, а не использование традиционного проца - это будет уже эмуляция) - это не классическое программирования и реализовав Ваш проц в эмуляторе - Вы очень мало продвинитесь к созданию проца даже, скажем, на FPGA
С моей точки зрения, продуманности подхода в предлагаемой модели проца - нет.Для того тема и создана, чтобы продумать подход до его реализации.
процом создаётся дескриптор, адрес которого загружается в спец регистр MMU и содержимое которого MMU потом кеширует у себя внутри, что бы не лазить каждый раз в медленное озу, а при переключении контекста загружается адрес нового дескриптора и т.д.Именно это и предлагалось, с учётом того, что дескриптор может находиться в кеше, ОЗУ или свопе и для каждой имеющейся моды ( пусть даже их имеется только три "классических" ) - процессор может загрузить дескриптор заранее и переключать его сменой моды.
...
Пусть даже у нас только три моды, но сколько отдельно настраиваемых страниц памяти хочется иметь в 4Гб адресного пространства каждой моды - 8 ( как у PDP-11 ) или всё-таки больше ?
Пусть даже у нас только три моды
Как мне кажется, основная причина появления режима Supervisor, так же DataSpace - попытка увеличить доступную для приложения память с 64 кб на что то побольшее. Поэтому смысла увеличивать количество режимов работы процессора не вижу. По идее - даже три (как и dataspace) - пока никак не просматривается - для чего? - в 32-битном режиме. Для 16-битном - да, там всё понятно.
Идём дальше. Почему может понадобиться наличие страниц в адресуемом 4гб пространстве. Я пока вижу след. сценарии:
- Доступ из ядра в адресное пространство пользовательского процесса
- Доступ из ядра к странице в/в
- Доступ из пользовательского процесс в адресное пространства ядра
- Доступ из пользовательского процесс в адресное пространства другого процесс
- Доступ из пользовательского процесс к странице в/в
- Единственная копия библиотеки (типа FCSRES FSCFSL) в памяти и отображение на неё в адресном пространстве ядра или пользовательского процесса
- Коду ядра или пользовательского процесса выделили кусок памяти при загрузке, оно захотело больше, пробуем расширить, а за сразу за физической памятью, которая была выделена - нужного количества свободного памяти нет - занята другим процессом - возможность строить из ненепрерывных сегментов физической памяти непрерывный сегмент виртуальной памяти окажется в такой ситуации плюсом.
Первые шесть пунктов по сути описывают один и тот же сценарий. А теперь, внимание, вопрос - возможность отобразить куски своей памяти на память других процессов в количестве 2 в 20 степени штук (реально, конечно, поменьше - примерно так на один - для себя то память тоже надо иметь) - оно в какой ситуации может понадобиться? Даже моя буйная фантазия отказывает. Доступ к памяти пары десятков библиотек и пары десятков других процессов - я думаю покроют 99 процентов возможных сценариев - то есть, скажем 64 сегмента в 4гб-ом адресном пространстве - почти за глаза. Ну, что бы точно гарантировать - пусть будет 1024 сегмента. И то с моей точки зрения уже будет напоминать некоторые современные программные пакету - а давайте сделаем, что бы ВСЁ было.
Дальше вопрос - откуда взялось адресное пространство на 42 бита? 4Тб - нафига столько?
поэтому объём физически доступной виртуальной памяти ограничен только объёмом SSD своп-диска ( для которого 4Тб уже не фантастика ).
Вы чего такого объёмного собрались напихать в (свопнутую) память и получить дикие тормоза на свопе?
У меня на комп 64 гига и мне его хватает более чем за глаза за ОДНИМ конкретным сценарием - когда я начинаю развлекаться с виртуалками. Но - о возможностях виртуализации пока никто не вспомнил, это раз, а во вторых - даже пара виртуалок и половина памяти в свопе - это будет крайне "весёлая" развлекуха.
Вообщем, если не развлекаться виртуалками - много памяти не требуется, если только не идти по пути раздутых приложений и ядра - а основной цимес PDP-11 с моей точки зрения - легковесные по объёму приложения. Извините, для приложений по 4 гига у меня есть Windows и архитектуры x86-x64 - вот пусть там и остаются.
Именно это и предлагалось, с учётом того, что дескриптор может находиться в кеше, ОЗУ или свопе
или свопе.
А вот тут мы получим развлекуху покруче варианта пары виртуалок с 16-гигами памяти на 4 гигах физической памяти плюс своп. Даже размещение в основном ОЗУ (которое по определению медленное по сравнению с кэш-память) - уже развлекуха. А кэш к тому добавляет дополнительного куража - MMU закэшировало дескриптор, а потом ядро взяло и изменило дескриптор в озу - получается, надо следить - кто куда и чего записал. Как бэ MMU не потребовался мощней проца.
- - - Добавлено - - -
Да, забыл про расширение памяти. RSX такой подход не использует, про другие системы ничего сказать не могу - если что то и попадалось - память молчит, зараза. Учитывая, что теоретически это ускорило бы выделение памяти (RSX вроде в такой ситуации выгружает в файл подкачки, а потом загружает в новое место с требуемым новым размером) - видимо, что то есть плохое, почему DEC решило так не выделять память. Но.. у меня мыслей на эту тему пока нет
откуда взялось адресное пространство на 42 бита?Из расчёта = 1024 моды по 32 бита. Win64 поддерживает 44 бита адреса, внутренняя шина адреса у x64 = 52 разряда, внешняя = 40 разрядов ( если правильно понимаю ). А какое принципиальное ограничение максимального объёма ОЗУ, адресуемого данной архитектурой, хотелось бы иметь?
Ну, чтобы точно гарантировать - пусть будет 1024 сегмента.Вот и я о том же - 8 сегментов по 512Мб уж слишком мало. 1024 сегмента по 4Мб - уже веселее ( точнее - от 512б до 4Мб с шагом 512б ).
И то с моей точки зрения уже будет напоминать некоторые современные программные пакеты - а давайте сделаем, что бы ВСЁ было.С каких-то ориентировочных оценок надо начинать - ведь главные проблемы не в конкретных значениях, а в архитектурных решениях.
А какое принципиальное ограничение максимального объёма ОЗУ
Это достаточно сложный вопрос.
Если брать с прицелом на железный проц и если не мультиплексировать данные-адрес то у нас - 32 проводника на данные и 32+неизвестно сколько на адрес, то есть 64+ - вот откуда ещё будет расти ограничение на физической размер памяти
По поводу Win и x86-x64, ЕМНИП, проблема максимально возможного размера памяти ещё в другом - там вроде бы надо через дескрипторы описать ВСЮ доступную физическую памяти страницами (то есть на каждую страницу - свой элемент в дескрипторе) и даже при странице в 4 мб объем этих дескрипторов получается неприлично большим, если памяти много. Именно поэтому MS и ограничила макс поддерживаемый размер физической памяти не смотря на возможности проца.
Надо будет попробовать собрать все мои мысли по поводу "PDP-11 моей мечты" в один файл, но боюсь это дело не ближайшего будущего - нужен практический опыт, что бы не спроектировать нереализуемый на практике проц (в FPGA, эмуляторы не в счёт, в эмуляторы можно всё что хочешь наворотить) :) Поэтому я и хочу поиграться с FPGA пока с "PDP-11 моей юности" :)
- - - Добавлено - - -
точнее - от 512б до 4Мб с шагом 512б
И опять вопрос - с практической точки зрения нафига нам шаг в 512 байт на 4 гигах адресного пространства? :)
Как мне кажется, основная причина появления режима Supervisor, так же DataSpace - попытка увеличить доступную для приложения память с 64 кб на что то побольшее. Поэтому смысла увеличивать количество режимов работы процессора не вижу. По идее - даже три (как и dataspace) - пока никак не просматривается - для чего? - в 32-битном режиме.Специальный режим, в котором после включения питания процессор работает только с внешними устройствами - нужен для того, чтобы стартовый код мог находиться не в микрокоде процессора, а обычном ПЗУ по нулевому адресу моды супервизора. Выпадение в HALT и другие напасти также должны автоматически обрабатываться системным ПЗУ моды супервизора.
Проще говоря, мода супервизора - это режим пульта.
- - - Добавлено - - -
И опять вопрос - с практической точки зрения нафига нам шаг в 512 байт на 4 гигах адресного пространства?Изучение интеловских документов по работе с памятью подсказало, что сделать можно иначе.
Оставить 8 сегментов ( которых в DEC называют "страницами" ) и дать каждому сегменту по 1024 страницы ( которых в DEC называют "блоками" ). Тогда общее число страниц в моде будет 8К при размере страницы 512К.
Если принять старый интеловский лимит для 32-разрядных MMU в миллион страниц, то такое количество страниц позволяет иметь 128 мод. А раз по меркам 10-летней давности 128 мод не пугают, то по современным меркам и 1024 моды не сильно страшны.
- - - Добавлено - - -
В интел ( насколько я понял ) применяется чисто страничная организация памяти, когда вся толпа флагов и признаков режима использования страницы хранится в её дескрипторе. Однако, все флаги и признаки можно разделить на имеющие отношение к аппаратуре и имеющие отношение к процессу-владельцу страницы. Смешанная сегментно-страничная организация памяти выделяет все общие свойства страниц процесса из дескрипторов и хранит их отдельно - в специальной "таблице регионов", объединяющей ссылки на дескрипторы всех страниц процесса с общими свойствами.
При таком подходе, возможно - есть смысл не задавать фиксированное количество регионов в моде ( 8 или 1024 ), позволив каждому процессу создавать столько наборов страниц, сколько надо.
Например, таблица первого уровня - может содержать 1024 ссылки на описатель региона ( все на один, каждая на свой или как угодно ещё ). Описатель региона задаёт свойства региона и содержит ссылки на описатели страниц. Для полного заполнения одного "атомарного региона" ( занимающего одну ссылку в таблице регионов ) нужно 8 страниц по 512К. Соответственно, полные регионы имеют шаг размера 4Мб, а минимальное изменение размера региона = 512К.
Уважаемые гуру, обьясните простому смертному что есть мода в Вашем разговоре? Это набор регистров аналогичный pdp-шным PAR/PDR?
Неплохо бы послушать "на пальцах" про реализацию MMU на pdp11,vax,mc68000,arm,x86,alpha,pa-risc чтобы было перед глазами некое сравнение. Хочется чтобы проц мог и в 64кб физической памяти организовать многозадачную OS так же легко как и в 640Mb и в 4GB и в 4TB. Ясно что для этого MMU должен иметь микрокод который бы задавал размер элементов-описателей страниц, и этот самый микрокод заливался при старте компьютера BIOS-ом в зависимости от количества физического ОЗУ (а возможно MMU должен иметь в себе отдельное ОЗУ для описателей страниц чтобы не тормозить рабочее ОЗУ).
Уважаемые гуру, обьясните простому смертному что есть мода в Вашем разговоре?Мода - это номер предварительно загруженного в MMU набора таблиц трансляции адресов, выбираемого битами моды в PSW.
Это набор регистров аналогичный pdp-шным PAR/PDR?Проблема MMU PDP-11 в том, что память не надо свопить. Когда память надо свопить - приходится хранить отдельный описатель для каждого минимального выделения памяти. В 64К адресного пространства PDP-11 минимальных выделений памяти было 1024. В интел для 32-разрядных MMU принято иметь миллион минимальных выделений, называемых "страница". В такой терминологии у MMU DEC не 8 страниц, а 1024 страницы, объединённых в 8 регионов.
Но MMU DEC не надо свопить отдельные страницы, поэтому все страницы мапятся одним махом - через регион, задающий их общие свойства.
Хочется чтобы проц мог и в 64кб физической памяти организовать многозадачную OS так же легко как и в 640Mb и в 4GB и в 4TB. Ясно что для этого MMU должен иметь микрокод который бы задавал размер элементов-описателей страниц, и этот самый микрокод заливался при старте компьютера BIOS-ом в зависимости от количества физического ОЗУ (а возможно MMU должен иметь в себе отдельное ОЗУ для описателей страниц чтобы не тормозить рабочее ОЗУ).Отличная идея - у интел тоже есть возможность задавать размер страницы при инициализации процессора, выбирая из 3 вариантов: 4К, 2М, 1Г.
Проще говоря, мода супервизора - это режим пульта.
У DEC режим супервизора - это не режим пульта! Это третий режим работы - типа пользовательского со своим набором PAR/PDR. В RSX-11M-Plus есть поддержка этого режима и в него можно загнать, скажем, резидентную библиотеку FCS, обычно собирается с именем FCSFSL.
Ещё раз - ЭТО НЕ ПУЛЬТОВЫЙ РЕЖИМ!
- - - Добавлено - - -
что есть мода в Вашем разговоре
Насколько я понял - первоначальная идея моды у Патрона - попытка ускорить по крайне мере описание отображения виртуальной памяти в физическую при переключении контекста процессов.
В PDP-11 три "моды" (режима работы процессора) и три набора PAR/PDR (которые реализованы как сверхОЗУ в MMU - по крайне мере такую аналогию можно провести). Соответственно, если пользовательский процесс обращается за обслуживанием к ядру или происходит прерывание - происходит переключение режима работы процессора (моды) по информации из вектора прерывания - и вот уже мы работаем с другим (ранее загруженным) набором PAR/PDR. И только если нужно переключиться с одного процесса на другой, когда оба работают в одном режиме работы процессора (планировщик активирует другой процесс, например) (в одной моде) - тогда нужно перезагрузка PAR/PDR.
У Патрона попытка ускорить этот процесс за счёт того, что количество режимов работы процессора резко увеличивается, у каждого свой набор PAR/PDR - мы их когда то проинициализировали - и вуаля - значительно реже их перезагружаем.
Проблема только в том, что при большом количестве памяти и/или маленьком размере страницы (то, что у PDP-11 64 кб и 8 кб) - этих самых PAR/PDR (если использовать аналогичный PDP-11 механизм описания страниц и работы MMU - только расширить на большие размеры памяти - физ и вирт) получается чуть больше, чем дохера.
Поэтому с моей точки зрения - не взлетит. Нужно думать - как уменьшить или реализовывать другой механизм
- - - Добавлено - - -
64кб физической памяти организовать многозадачную OS
при 32-битном процессоре (и размере команды (минимум) в 4 байта, а не 2) - думаю - это тоже утопия. Нэ влэзит
- - - Добавлено - - -
В дополнение к описанию моды.
Если реализовывать на эмуляторе - может и взлетит, только или памяти будет жрать дохера или MMU будет работать медленно.
А если пихать в FPGA - более чем уверен, что или не влэзит (памяти там все токи чуть меньше, чем недохера) или MMU будет тормозить аки Конь Древний На Борозде :)
- - - Добавлено - - -
И поскольку я опять запутался в терминах Патрона, определение моих терминов (может, DEC использует свои, более правильные - но я их щас вспомнить не могу, а лезть в доки лень)
Окно в виртуальном адресном пространстве - грубо говоря - начиная с какого виртуального адреса и сколько отобразить на физический адрес.
С какого - с границы 8 кб
Сколько - от 64 байт до 8 кб.
Почему с границы 8 кб - потому что регистров-описателей (регистров базы) - всего восемь
Почему от 64 байт (100 в восьмеричном) - потому что MMU берет содержимое регистра PAR (16 бит) (номер регистра - старшие три бита виртуального адреса - номер окна) сдвигает его влево на шесть бит (и вот вылез минимальный блок в 64 байта) (теперь 22 бита, младшие шесть - нули), берет виртуальный адрес (16 бит), режет старшие три бита (номер окна) (на самом деле ничего он не режет - просто берет младшие 13 бит) и складывает, формируя физический адрес (22 бита)
Сколько отобразили - ЕМНИП - в PDR - как количество 64 байтных блоков
- - - Добавлено - - -
С ваксами в живую дело не имел - поэтому как оно там - даже с памятью-изменщицей не скажу - надо листать талмуды. Но учитывая наличие режима совместимости - видимо не кардинально отличающееся
У DEC режим супервизора - это не режим пульта! Это третий режим работы - типа пользовательского со своим набором PAR/PDR.А в 32-разрядном режиме - это режим пульта. Другие варианты организации режима пульта: 1) микропрограмма в CPU; 2) специальный контроллер режима пульта с поддержкой в CPU; 3) железный пульт. Отдельная мода пульта выглядит на порядок проще любого другого варианта.
Окно в виртуальном адресном пространстве - грубо говоря - начиная с какого виртуального адреса и сколько отобразить на физический адрес.
С какого - с границы 8 кб
Сколько - от 64 байт до 8 кб.
Почему с границы 8 кб - потому что регистров-описателей (регистров базы) - всего восемь
Почему от 64 байт (100 в восьмеричном) - потому что MMU берет содержимое регистра PAR (16 бит) (номер регистра - старшие три бита виртуального адреса - номер окна) сдвигает его влево на шесть бит (и вот вылез минимальный блок в 64 байта) (теперь 22 бита, младшие шесть - нули), берет виртуальный адрес (16 бит), режет старшие три бита (номер окна) (на самом деле ничего он не режет - просто берет младшие 13 бит) и складывает, формируя физический адрес (22 бита)
Сколько отобразили - ЕМНИП - в PDR - как количество 64 байтных блоковА какими кусками свопить? Если кусками по 4Мб, которых в 32-битном адресном пространстве всего 1024 - то интел с 1М страниц по 4Кб выглядит в 1024 раза более экономно. Если свопить кусками по 8Кб, которых в 4Гб будет 512К, то предлагается ли для каждого из 512 тысяч этих 8Кб окон иметь собственную пару PAR/PDR? А если нет - то как определить, какое из окон уже в памяти, а какое ещё надо загрузить из свопа?
В том и дело, что концепция PAR/PDR плохо масштабируется для перехода от 16-разрядного пространства без свопа к 32-разрядному со свопом.
- - - Добавлено - - -
Идею виртуальных пространств со свопом можно показать на простом примере. Допустим, у нас есть архитектура с адресным пространством из 10 адресов, работающая на машне с 3 адресами физического ОЗУ и 10 адресами свопа. Когда программа заказывает выделение памяти в 10 адресов - операционка возвращает указатель на первый адрес.
Потом программа начинает загружать данные в память.
Для виртуального адреса 0 MMU выделяет физический адрес 0
Для виртуального адреса 1 MMU выделяет физический адрес 1
Для виртуального адреса 2 MMU выделяет физический адрес 2
Для виртуального адреса 3 MMU выгружает адрес 0 в своп по адресу 0 и выделяет физический адрес 0
Для виртуального адреса 4 MMU выгружает адрес 1 в своп по адресу 1 и выделяет физический адрес 1
Для виртуального адреса 5 MMU выгружает адрес 2 в своп по адресу 2 и выделяет физический адрес 2
Для виртуального адреса 6 MMU выгружает адрес 0 в своп по адресу 3 и выделяет физический адрес 0
Для виртуального адреса 7 MMU выгружает адрес 1 в своп по адресу 4 и выделяет физический адрес 1
Для виртуального адреса 8 MMU выгружает адрес 2 в своп по адресу 5 и выделяет физический адрес 2
Для виртуального адреса 9 MMU выгружает адрес 3 в своп по адресу 6 и выделяет физический адрес 0
Потом программа читает данные из памяти.
Для виртуального адреса 0 MMU выгружает адрес 0 в своп по адресу 9 и загружает из свопа адрес 0 по адресу 0
Для виртуального адреса 1 MMU выгружает адрес 1 в своп по адресу 7 и загружает из свопа адрес 1 по адресу 1
Для виртуального адреса 2 MMU выгружает адрес 2 в своп по адресу 8 и загружает из свопа адрес 2 по адресу 2
Для виртуального адреса 3 MMU выгружает адрес 0 в своп по адресу 0 и загружает из свопа адрес 3 по адресу 0
Для виртуального адреса 4 MMU выгружает адрес 1 в своп по адресу 1 и загружает из свопа адрес 4 по адресу 1
Для виртуального адреса 5 MMU выгружает адрес 2 в своп по адресу 2 и загружает из свопа адрес 5 по адресу 2
Для виртуального адреса 6 MMU выгружает адрес 0 в своп по адресу 3 и загружает из свопа адрес 6 по адресу 0
Для виртуального адреса 7 MMU выгружает адрес 1 в своп по адресу 4 и загружает из свопа адрес 7 по адресу 1
Для виртуального адреса 8 MMU выгружает адрес 2 в своп по адресу 5 и загружает из свопа адрес 8 по адресу 2
Для виртуального адреса 9 MMU выгружает адрес 3 в своп по адресу 6 и загружает из свопа адрес 9 по адресу 0
А в 32-разрядном режиме - это режим пульта
Если начинать ТАК жонглировать терминами - мы застрянем в самом начале!
В PDP-11 (от которого мы пляшем - это не режим пульта. Нужен режим пульта - так и пусть будет режим ПУЛЬТА!
А какими кусками свопить?
Зачем свопить?? У нас что - оперативка по 10 баксов за байт???
Нужен режим пульта - так и пусть будет режим ПУЛЬТА!Предлагается, чтобы после включения питания - мода супервизора была замаплена на 4Гб адресов внешних устройств, где по адресу 0 начинается пультовое ПЗУ. В принципе - загруженная операционка может позже эту моду перемапить, чтобы установить собственный обработчик исключительных ситуаций, но при сбросе питания и обнулении ОЗУ - мапинг моды супервизора на пространство ввода-вывода автоматически восстанавливается.
Зачем свопить?? У нас что - оперативка по 10 баксов за байт???Когда у нас есть два процесса, каждый из которых имеет доступ к собственному виртуальному адресному пространству 4Гб, то в общем случае без свопа не обойтись даже на машине с 4Гб ОЗУ. А если у нас 64 процесса или 1024 процесса - тогда и подавно. Поэтому 32-разрядные архитектуры изначально проектируют со свопом.
мода супервизора
Пульта!!
два процесса
виртуальному адресному пространству 4Гб
Операционка будет выделять программе 4 гига оперативки, даже если программе нужно 100 байт???
Пульта!!Если даже перемапленная с пультового ПЗУ в ОЗУ мода обработки исключительных ситуаций больше похожа на "моду пульта" - пусть будет мода пульта.
Операционка будет выделять программе 4 гига оперативки, даже если программе нужно 100 байт???Архитектуры со свопом могут работать гораздо быстрее, чем без свопа, потому что операционка получает возможность запускать на выполнение файлы любого размера, просто помечая их как "временные файлы подкачки" и без загрузки файла в память - просто передавая управление на "смотрящий в пустоту" стартовый адрес. Тогда во время исполнения программы в память попадут только те страницы файла исполняемой программы, куда будут происходить переходы и вызовы в коде.
За счёт этого гигабайтные файлы стартуют на выполнение за доли секунд, тогда как при отсутствии в архитектуре свопа - их надо или целиком загружать в память, или использовать убогую концепцию оверлеев.
пусть будет мода пульта.
Человек читает - основана на архитектуре PDP-11. Человек читал доку по PDP-11 и он знает, что такое режим супервизора на PDP-11. Человек видит - мода супервизора... Профит!
Архитектуры со свопом могут работать гораздо быстрее
просто помечая их как "временные файлы подкачки" и без загрузки файла в память - просто передавая управление на "смотрящий в пустоту" стартовый адрес. Тогда во время исполнения программы в память попадут только те страницы файла исполняемой программы, куда будут происходить переходы и вызовы в коде.
Назовём единицу выделения памяти (и подкачки) - страницей.
Только здесь. Больше нигде (я уже начинаю запутываться в терминах, значение которых отлично от тех, к которым я привык в доках по PDP-11)
Операционка пометила запускаемую программу как временный файл подкачки (кстати, в Windows аналогичный механизм носит название - файл, отображённый в память, что позволяет легко обойтись без специальных пометок, что бы не дай бог не вмешался диспетчер файла подкачки и не выгрузил в наш (временный) файл подкачки что то ещё) и передала управление на нулевую страницу - пусть там стартовый адрес. Что происходит дальше.
Операционка - я передаю управление на страницу 0
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 20
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 21
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 100
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 101
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 120
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 12
MMU - упс, памяти нет - подгружаем.
Программа - я передаю управление на страницу 45
MMU - упс, памяти нет - подгружаем.
....
Пусть размер программы - 150 страниц.
Вы серьёзно думаете, что в 150 запросов чтения по странице выполнятся быстрее, чем один, читающий 150 страниц за раз? (помните, у нас памяти сейчас у нас... как грязи)
Вы серьёзно думаете, что в 150 запросов чтения по странице выполнятся быстрее, чем один, читающий 150 страниц за раз?Это называется "отображение файлов в память" и так сейчас работают все операционки. Но ничто не мешает иметь два варианта архитектуры - со свопом и без. В архитектурах без свопа есть только один способ, как при старте программы не загружать её в память целиком - использовать оверлеи.
- - - Добавлено - - -
Возможно не все знают, что программа DIR в RT-11 v5.0 стала оверлейной не потому, что не лезла в память, а для того, чтобы при обычном просмотре каталога с диска считывались только первые блоки программы и лишь при использовании различных экзотических режимов - подгружался оверлей, обрабатывавший дополнительные ключи запуска.
Это называется "отображение файлов в память
кстати, в Windows аналогичный механизм носит название - файл, отображённый в память
Похоже, чтение идёт избранных мест.
В архитектурах без свопа есть только один способ, как при старте программы не загружать её в память целиком
ЗАЧЕМ МОЖЕТ ПОНАДОБИТЬСЯ НЕ ЗАГРУЖАТЬ ПРОГРАММУ В ПАМЯТЬ ЦЕЛИКОМ, если у нас не монструозные программы и памяти как грязи??
- использовать оверлеи.
Расскажите это динамически-загружаемым библиотекам, которые, кстати, существовали уже в RSX-11M-Plus, а я делал для RSX-11M в восемьдесят-лохматом году.
Не знаю как там с юникс-системах (на 32-битных процах), но в PDP-11 оверлеи - это способ ПОВТОРНО использовать адресное пространство в первую очередь. А ещё был такой вариант - оверлеи, резидентные в памяти, в системах с MMU (насчёт поддержки под XM монитором не скажу - но по идее должна быть, а уж в RSX - даже в M были) - когда программа целиком располагалась в памяти, но тем не менее использовала оверлеи.
- - - Добавлено - - -
с диска считывались только первые блоки программы
Что даёт хорошо заметный эффект ускорения работы программы на чём нибудь типа DX01 - но нахрен не нужно уже даже на дисках типа RK05 при том размере, который у DIR. Или Ваш замечательный 32-битный проц Вы планируете использовать вместе с DX01??
Расскажите это динамически-загружаемым библиотекамВ системах с файловым отображением памяти - они просто отображаются (без обращения к диску), а в RSX - загружаются с диска только те подпрограммы динамической библиотеки, к которым идёт обращение, или всю библиотеку надо загружать целиком?
Но зачем отказывать любому из двух вариантов в праве на существование. Сэмулировать можно обе архитектуры, но портировать RSX конечно проще на вариант без свопа.
Уточнение.
Я не против файла подкачки - потому что есть ситуации, когда он МОЖЕТ пригодиться. Но складывается впечатление, что у Вас это идея-фикс, раз всплыло аж на первой странице.
- - - Добавлено - - -
в RSX - загружаются с диска только те подпрограммы динамической библиотеки, к которым идёт обращение, или всю библиотеку надо загружать целиком?
Вся целиком.
В RSX-11M она должна быть загружена в память до того, как будет запущена программа, которая будет к ней обращаться (FCSRES обычно в VMR загружают) , в RSX-11M-Plus её грузит сама система как только запускается программа, которая к ней прилинкована. И насколько мне не изменяет память, PLUS может при дефрагментации памяти может или двигать её (есть запущенные проги, которые её используют) или вообще выкинуть из памяти (нет запущенных прог, которые её используют).
Но для RSX-11M я делал прогу, которая достаточно сильно воспроизводит поведение динамических библиотек в PLUS-е. Жаль только в смутные времена (когда СМ-ка уже умирала) я не всё перетащил, что было (в первую очередь на лентах), на ДВК - в том числе свои проги, в том числе такую экзотику, как DECNET-RT. Щас сильно жалею..
Но зачем отказывать любому из двух вариантов в праве на существование
Выше ответил.
- - - Добавлено - - -
Просто учитывая накладные расходы и задержки - это то, что надо КРАЙНЕ ХОРОШО продумать - а не реализовывать по принципу - шоб було.
В варианте без свопа 32-разрядный MMU может быть весьма похож на 16-разрядный. На шине будут видны два набора 16-разрядных PAR и PDR - системный и предыдущей моды ( по номеру из битов предыдущей моды в PSW ). 64 регистра PAR могут разбить 4Гб адресов на 64 окна максимальным размером 64Мб и минимальным 64Кб ( с шагом 64Кб ). Если флаг PageWritten перенести в 4-й бит - 16-разрядный PDR позволяет иметь поле PLF длиной 10 бит ( что при странице 64М даёт минимальный размер страницы 64К и шаг размера 64К ).
Для 1024 мод от MMU потребуется 1024*64*16*2 = 2Мб внутренней памяти.
Возможно лучше, чтобы пара 16-разрядных PAR+PDR занимала один 32-разрядный регистр MMU, причём более часто используемый регистр был в младшем слове.
В варианте без свопа 32-разрядный MMU
С моей точки зрения - MMU о свопе вообще ничего не должен знать. Его задача (крайне быстро) отобразить виртуальный адрес на физический, проверить возможность записи (если команда пытается что то записать в память) или выдать прерывание - если виртуальный адрес не отображён на физический или писать нельзя. Всё. Своп - прерогатива операционки (если она будет его поддерживать).
Про остальное ничего пока сказать не могу - это уже конкретика (причём конкретика одного блока проца) - и что бы ответить на неё - нужна архитектура в целом и ответ на вопрос - зачем (нам это может понадобиться)? А мы пока ещё далеко в самом начале проекта архитектуры.
В таком варианте нулевой бит PDR не используется и в системе со свопом его можно отдать под флаг "страница в свопе". Тогда подсистема свопа в операционке должна будет иметь собственные дополнительные дескрипторы страниц и учитывать размер страницы ( из PLF ) при свопе.
- - - Добавлено - - -
С моей точки зрения - MMU о свопе вообще ничего не должен знать. Его задача (крайне быстро) отобразить виртуальный адрес на физический, проверить возможность записи (если команда пытается что то записать в память) или выдать прерывание - если виртуальный адрес не отображён на физический или писать нельзя. Всё. Своп - прерогатива операционки (если она будет его поддерживать).Для поддержки свопа - в PDR должен быть флаг "страница не в памяти", вызывающий прерывание при обращении к странице.
- - - Добавлено - - -
В принципе - в качестве флага "страница не в памяти" можно использовать значение поля доступа PDR - NonResident ( 00 ), при котором MMU на попытки обращения к странице будет выдавать прерывание по специальному вектору ( чтобы регистр ошибок MMU каждый раз не читать ).
если виртуальный адрес не отображён на физический
"страница не в памяти",
Который фактически будет использовать не MMU (ему как бы фиолетово - по какой причине виртуальный адрес не отображён на физический), а операционка. А раз его будет использовать (только) операционка - то вопрос - нужен ли он в регистре MMU. Хотя для упрощения дел - можно завести для MMU два вектора (а то и больше) - и использовать разные вектора для разных событий - не отображена память, память в свопе, попытка записи.. - вот тогда пригодится для вычисления вектора. Но опять же - это уже конкретика гораздо более позднего времени - детали реализации.
Есть механизм
- Вычисляем номер страницы, берём содержимое соответствующего регистра PAR, сдвигаем, складываем - получаем физический адрес
Есть конкретика
- Номер страницы - старшие три бита виртуального адреса - даёт нам номер регистра PAR, который мы сдвигаем на шесть бит влево и складываем с адресом внутри страницы (без старших трёх бит) и получаем физический адрес
Пока нет механизма - конкретикой заниматься не стоит - поменяется 100500 раз. Весь мой опыт программирования говорит об этом.
Номер страницы - старшие 6 бит виртуального адреса - даёт нам номер регистра PAR, который мы сдвигаем на 10 ( 26 ) битов влево, складываем с 32-разрядным адресом внутри страницы (без старших 6 битов) и получаем физический 42-разрядный адрес.
Шож Вас так тянет на конкретику не вовремя..
Вот Вам архитектурное решение.
- Что бы сохранить возможность перекомпиляции существующих программ на Macro-11 малой кровью - шестой регистр - указатель стека, а седьмой - указатель команд - в обеих режимах (16 и 32 битных). Независимо от того - сколько и каких ещё будет регистров :)
Что не осилю никак. А зачем разрядность физического адреса больше разрядности виртуального? Получается какая-то сегментная адресация имени 8086/8088
нужен ли он в регистре MMUMMU знает только то, что есть у него в регистрах. Чтобы обращение к странице вызвало прерывание до обращения MMU к физической памяти - содержимое PDR должно быть несовместимо с происходящим ( вроде попытки записи в запрещённую для записи страницу ). Поэтому без некого признака "отсутствующей страницы" в PDR никак не обойтись. Благо - такой признак есть в виде значения NonResident в ACF PDR.
Что не осилю никак
Чего там осиливать - в PDP-11 было так же
Получается какая-то сегментная адресация имени 8086/8088
Там было на уровне процесса, а в PDP-11 на уровне операционки - процесс это как бы не видит (ценой 64 кб)
Та же идея в PDP-2032 - процессу доступно (до) 4 Гб, операционка видит (до) 4Тб
- - - Добавлено - - -
Поэтому без некого признака "отсутствующей страницы" в PDR никак не обойтись
А MMU фиолетово - почему страницы нет в памяти (не-отображали или в-файле-подкачки-поэтому-не-отобразили) - нет и всё. Это интересно операционке - когда будет разбираться - программер сфолтнул или надо бы подгрузить. Так то если не использовать многовекторность - получится бит, который MMU вообще никак не будет трогать
Что бы сохранить возможность перекомпиляции существующих программ на Macro-11 малой кровью - шестой регистр - указатель стека, а седьмой - указатель команд - в обеих режимах (16 и 32 битных). Независимо от того - сколько и каких ещё будет регистровТак и планировалось.
Кстати, одним из главных реальных преимуществ 64-разрядной архитектуры Intel считается появление дополнительных 8 регистров общего назначения, позволивших отказаться от старых соглашений передачи параметров при вызове подпрограмм и ввести новое, где все параметры как бы передаются через стек, но первыми словами стека считаются специально выделенные регистры общего назначения. Это позволяет вообще отказаться от кода пролога и эпилога у некоторых небольших подпрограмм стандартной библиотеки и существенно упростить доступ к параметрам вызова у большинства подпрограмм.
Чего там осиливать - в PDP-11 было так же
Это было в 70-х годах. прошлого века. Да и для совместимости софта прикладного. Одной задаче все равно было доступно не более 64к озу
А MMU фиолетово - почему страницы нет в памяти (не-отображали или в-файле-подкачки-поэтому-не-отобразили) - нет и всё.Когда операционка высвапливает страницу - страница из памяти не пропадает, но получает в PDR признак "не в памяти", хотя в физической памяти она по своему адресу есть. Если процесс обратится по этому адресу - операционка получит прерывание и если страница ещё не обнулена "системным обнулителем" - операционка просто заменит признак в PDR и процесс получит доступ к странице без её чтения операционкой из свопа.
Просто вспомнил первое впечатление когда после бейсика столкнулся (увидел) впервые листинг
программы на МАКРО-11 и у программиста который на тот момент пытался мне что то там базовое втолковать узнал про всю эту "регистровую математику, стэк, смещения и проч." - я подумал, почему
и кто решил, кто придумал что бы так сложно всё было??? теперь я примерно знаю не конкретных
людей конечно, но образ мышления тех для кого это "родной терновый куст"
Когда операционка высвапливает страницу - страница из памяти не пропадает, но получает в PDR признак "не в памяти", хотя в физической памяти она по своему адресу есть. Если процесс обратится по этому адресу - операционка получит прерывание и если страница ещё не обнулена "системным обнулителем" - операционка просто заменит признак в PDR и процесс получит доступ к странице без её чтения операционкой из свопа.
Я вот честно всё понял тут ! Гениально ! системщики ) вот почему они не тратят время
на заглавные буковки и скучно им с простыми смертными )))
Когда операционка высвапливает страницу - страница из памяти не пропадает, но получает в PDR признак "не в памяти", хотя в физической памяти она по своему адресу есть. Если процесс обратится по этому адресу - операционка получит прерывание и если страница ещё не обнулена "системным обнулителем" - операционка просто заменит признак в PDR и процесс получит доступ к странице без её чтения операционкой из свопа.
И каким боком при этом MMU?
и если страница ещё не обнулена "системным обнулителем"
Вопрос - а на хрена был поставлен признак - страница не в памяти? Может потому что её уже выгрузили или ещё не загрузили? Потому как ставить это признак для чего то ещё - зачем??
- - - Добавлено - - -
подумал, почему и кто решил, кто придумал что бы так сложно всё было
Потому что есть в любое время предел возможностей железа - это раз и потому что - наши отца так делали - значит и нам так делать - это два (хотя уже никто нихрена не помнить - какого хрена они так делали (а потому что раньше по другому не получилось бы - но не сейчас). Делать без понимания - почему - это наше всё.
И каким боком при этом MMU?Если MMU не может дать прерывание - страница загружена не будет. Но чтобы MMU дал прерывание - он должен "что-то заподозрить" ( вроде записи в страницу, запрещённую для записи ), но без признака "страница не в памяти" - MMU никак не может узнать, что страница не в памяти, потому что на самом деле страница всегда в памяти, но не всегда принадлежит тому процессу, который к ней обращается. В том и суть свопа, что одна и та же страница принадлежит куче процессов, но только у одного процесса-владельца для этой страницы сброшен в MMU флаг "страница не в памяти".
Вопрос - а на хрена был поставлен признак - страница не в памяти? Может потому что её уже выгрузили или ещё не загрузили? Потому как ставить это признак для чего то ещё - зачем??Операционка никак не может узнать, какими страницами процесс реально пользуется, а какими нет - все обращения идут напрямую от процесса через MMU в страницу. Поэтому для обнаружения страниц, к которым давно нет обращения - коварная операционка время от времени помечает все страницы, как "не в памяти" и если пометка продержалась до следующего захода - счётчик "забытости" страницы инкрементируется, чтобы когда память закончится - первой отправилась в своп самая забытая страница.
- - - Добавлено - - -
Чтобы не устраивать такие извращения - можно выделить самый младший бит PDR ( помеченный, как Not Used ) в качестве флага Not Used, который никогда не устанавливается MMU (но может быть установлен программно) и сбрасывается MMU при любом обращении к странице.
Чтобы не устраивать такие извращения - можно выделить самый младший бит PDR ( помеченный, как Not Used ) в качестве флага Not Used, который никогда не устанавливается MMU (но может быть установлен программно) и сбрасывается MMU при любом обращении к странице. Одного бита мало - не узнаешь самую забытую страницу, все забытые страницы будут одинаковыми.
А вообще, здешние беседы изрядно напоминают обсуждение количества ангелов, помещающихся на кончике иглы... :)
Название темы:32-разрядный процессор, полностью совместимый с архитектурой PDP-11. ПОЛНОСТЬЮ СОВМЕСТИМЫЙ.
Вопрос номер один, убивающий тему на корню - как им образом 32-битный процессор может быть ПОЛНОСТЬЮ СОВМЕСТИМЫМ с 16-битным процессором.
Учитывая, что диспетчером памяти управляет только операционка, но не пользовательские процессы - а значит им по барабану, как управлять MMU, а значит, перекомпиляция их под 32-бита не потребует изменения кода управления MMU, который есть только в операционной системе, который всё равно придётся переделывать, потому что может сохраниться только принцип работы MMU, но не особенности его настройки, а значит - код всё равно придётся лопатить сильно.
Вопрос номер два, режущий по живому. Для каких таких тайных целей, про которые я не смог догадаться, если конечно их можно озвучивать простым смертным - принцип работы MMU в своей сути
Номер страницы - старшие 6 бит виртуального адреса - даёт нам номер регистра PAR, который мы сдвигаем на 10 ( 26 ) битов влево, складываем с 32-разрядным адресом внутри страницы (без старших 6 битов) и получаем физический 42-разрядный адрес.
взят от PDP-11 - где он был создан таким из за ограничений технологий того времени и особенностей архитектур 16-битной PDP-11? Потому что - так делали наши отцы - значит и нам так делать? Без понимания - почему они так делали?
обсуждение количества ангелов, помещающихся на кончике иглы
Потом что с самого начала обсуждать конкретику реализации, когда стройного описания архитектуры нет и в помине. Кончик иглы несколько расширился - а никто этого не хочет понять.
С моей точки зрения - проект идёт в тупик. 1000 описателей распределения памяти, в каждый конкретный момент времени из которого используется 0.1 процента и необходимость перезагрузки которого возникает - какой там будет квант времени планировщика? Ой, у нас однозадачная операционка...
Потом что с самого начала обсуждать конкретику реализации, когда стройного описания архитектуры нет и в помине. Кончик иглы несколько расширился - а никто этого не хочет понять. Да нет, все проще. Зачем сочинять процессор, для которого нет и не будет софта?
для которого нет и не будет софта?
софт будет, если будет ОС + компиляторы.
Вопрос номер один, убивающий тему на корню - как им образом 32-битный процессор может быть ПОЛНОСТЬЮ СОВМЕСТИМЫМ с 16-битным процессором.
ну дак почему то никто не удивляется что Intel тянет в 64х битных процах совместимость с 8086 еще и всё вроде работает
Intel тянет в 64х битных процах совместимость с 8086
Вот как раз таки в 64х битных виртуальный 8086 режим и выкинули. На его месте теперь 32х битный режим, для совместимости. Кому нужен 8086, вынужден пользоваться DosBox.
ну дак почему то никто не удивляется что Intel тянет в 64х битных процах совместимость с 8086 еще и всё вроде работает Работает, да...
Чуток истории. 1 февраля 82-го года интеля предложили 80286. Не прошло и десяти лет, как Микрософт в мае 90-го предложила полноценную ОСь для него, полностью использующую возможности его Protected Mode - Win 3.0, поддерживающую, кстати, и совместимость. Далее, в октябре 85-го интеля предложили 80386. Опять же, не прошло и 10 лет, как в сентябре 94-го Микрософт предложил для протектед моды этого проца нормальную ОСь - WinNT 3.5...
Ладно, допустим, мы сегодня сочиним 32-битный процессор, полностью совместимый с PDP-11. Где тот Микрософт, который сочинит нам нормальную 32-битную ОСь для него, пусть даже и через 10 лет?
Ладно, допустим, мы сегодня сочиним 32-битный процессор, полностью совместимый с PDP-11. Где тот Микрософт, который сочинит нам нормальную 32-битную ОСь для него, пусть даже и через 10 лет?
я так понимаю что если сделать GNU совместимый компилятор, то потенциально под этот проц можно портировать Linux и груду софта
Одного бита мало - не узнаешь самую забытую страницу, все забытые страницы будут одинаковыми.Системный планировщик памяти регулярно ( примерно раз в секунду ) обходит регистры PDR всех запущенных процессов, для каждого PDR прибавляет содержимое его бита Not Used к счётчику "забытости" этой страницы процесса и заново устанавливает этот бит в 1.
- - - Добавлено - - -
каким образом 32-битный процессор может быть ПОЛНОСТЬЮ СОВМЕСТИМЫМ с 16-битным процессором.Имеется в виду режим эмуляции 16-разрядной архитектуры, автоматически активируемый процессором при переключении на 16-разрядный процесс. В этом режиме любое количество любых операционок PDP-11 могут загружаться и работать как обычные 16-разрядные процессы, создаваемые пультом или 32-разрядной операционкой. Таким образом архитектура позволяет одновременное выполнение и 16-разрядных, и 32-разрядных процессов.
В принципе - можно предусмотреть 32-разрядную команду, задающую количество последующих 16-разрядных слов, интерпретируемых процессором как 16-разрядный код. Но для такого 16-разрядного кода уже будут некоторые ограничения, по сравнению с кодом 16-разрядного процесса.
Для каких таких тайных целей, про которые я не смог догадаться, если конечно их можно озвучивать простым смертным - принцип работы MMU в своей сути взят от PDP-11Для простоты портирования RSX. Если делать нормальный диспетчер памяти, позволяющий отображать файлы в память не кусками по 64Мб, а хотя бы кусками по 512Кб ( примерно столько современные HDD считывают во внутренний буфер при любом обращении к диску ) - о похожести организации MMU на MMU PDP-11 придётся забыть.
Но если забыть об эффективном отображении файлов - 32-разрядный MMU с поддержкой свопа кусками по 64Мб может отличаться от MMU PDP-11 только количеством регистров PAR/PDR ( 64 вместо 8 ) и небольшими изменениями логики работы.
Вряд ли можно разрешать стеку 32-разрядного процессора обращаться к адресам, не кратным 4 - это даст массу нежелательных побочных эффектов. Но если для стека обязательно двусловное выравнивание - нет смысла отказываться от двусловного выравнивания PC. Можно также отказаться от "прерываний нечётности", сделав временно недоступными младшие биты регистров, используемых при вычислении адреса. Тогда при байтовой адресации относительно любого регистра - будут использоваться все его биты, при словной - все биты, кроме младшего, а при двусловной - все биты, кроме двух младших. Остальные операции будут читать/писать все биты регистра, поэтому каждая четвёртая команда INC PC будет смещать адресацию относительно PC на одно двойное слово.
Но если к расположению команд в памяти предъявляется требование двусловного выравнивания - значит все команды должны состоять из двух слов. При этом возможны три разных класса команд:
1. Legacy ( "старые" ) - команды с нулевым старшим словом, полностью идентичные командам PDP-11.
2. Extended Legacy ( "расширенные" ) - команды PDP-11 с битами расширения в старшем слове.
3. Pure 32 ( "новые" ) - команды с 32-разрядным кодом.
Такой подход выглядит в максимальной степени "совместимым с архитектурой PDP-11".
Для построения полноценного набора команд 32-разрядного процессора - вполне достаточно единственного бита расширения, превращающего команды словной адресации PDP-11 в команды двусловной адресации ( т.е. превращающего, например - команду MOV X,Y из команды, пересылающей одиночное слово, в команду, пересылающую двойное слово ).
Но в принципе, могут быть полезными также:
- бит расширения номера регистра приёмника;
- бит расширения способа адресации приёмника;
- бит расширения номера регистра источника;
- бит расширения способа адресации источника;
Если сразу ввести эти биты в стандарт Extended Legacy - тогда им лучше располагаться в начале второго слова команды, а бит "двусловной модификации" в таком случае будет следующим.
Кстати - даже в базовом наборе команд 32-разрядного процессора полезно иметь не только "старые" и "расширенные", но и некоторые "новые" команды, такие как 32-разрядный вариант команды BR, хранящий смещение PC не в младшем байте, а в младшем слове команды.
Lethargeek
14.09.2017, 15:36
Не совсем всё понял, и не уверен, что означает "совместимый с архитектурой", но сможет ли старый код весь правильно работать с таким подходом? В частности, код самомодифицируемый. КМК легаси-команды вообще не должны бы видеть нечётные слова при выравнивании, и адреса для их пропуска следует транслировать дополнительно.
- - - Добавлено - - -
кстати, этот документ был знаком? как в dec видели развитие pdp:
http://gordonbell.azurewebsites.net/digital/pdp11_arch_enhance_strategy_75.pdf
Не совсем всё понял, и не уверен, что означает "совместимый с архитектурой", но сможет ли старый код весь правильно работать с таким подходом?Идея такая, что старый код должен работать в старых операционках ( ведь реальный старый код без системных вызовов не бывает ), поэтому для запуска старого кода предусмотрены специальные 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
14.09.2017, 18:15
ведь реальный старый код без системных вызовов не бывает
Это почему это не бывает? "Старый код" - не только лишь законченные программы, но и чья-нибудь библиотечка старых этюдов обработки информации в памяти, где ни единого системного вызова.
поэтому для запуска старого кода предусмотрены специальные 16-разрядные процессы, выполняемые не на основном 32-разрядном ядре, а на специальном сопроцессоре,
О какой тогда "полной совместимости" идёт речь? Я подумал, что планировалась бинарная.
А тут даже полная совместимость на уровне ассемблерных исходников под вопросом.
Легаси-команды - это полноценные 32-разрядные команды с нулевым старшим словом кода команды. Они нужны не для запуска старого двоичного 16-разрядного кода в 32-разрядных процессах, а для упрощения переделки кодогенераторов старых компиляторов.
Не пойму, в чём уж такая проблема и зачем для её решения порождать/усугублять проблему несовместимости :v2_conf2:
Чтобы старый ассемблерный текст, скомпилированный для 32-разрядной архитектуры, имел отличия в работе от работы на PDP-11 - нужно очень постараться. Что-то вроде: ADD #4,PC или MOV 2(SP),(SP) | RETURN - сработает по-разному ( и поэтому выдаст предупреждение при компиляции ), но команды не использующие явно PC и SP для косвенно-индексной адресации - сработают одинаково.
Так что насчёт модифицируемого кода? Вот хотя бы перед вызовом в тело процедуры вписать константу. А потом чтоб тот же адрес в том же регистре послужил базой для доступа к таблице какой-нибудь (или же для вычисления базы). А как автоинкременты должны работать? Неизвестно же, это шаг на следующую команду или на данные.
О какой тогда "полной совместимости" идёт речь? Я подумал, что планировалась бинарная.Бинарная совместимость обеспечивается в 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
14.09.2017, 20:56
Такой код - в любом режиме будет работать одинаково: ...
а такой?
...
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
MOV (R1)+,(R2)+
...
вот ЧТО здесь пересылается? ;)
В 32-разрядном режиме полная бинарная совместимость в принципе невозможна, а частичная имеется на уровне легаси-команд.
А если сделать так: просто расширить регистры и шину адреса/данных до 32-х бит, а Legacy команды при записи будут выдавать ноль в старших 16 битах.
С точки зрения программиста это будет выглядеть так, как будто ОЗУ и ПЗУ теперь двухслойное, в первом слое хранятся 16-битные данные, во втором - дополнительные старшие 16 бит. Если второй слой содержит только нули, то будет выполняться 16-битная программа, но если там не нули, то это 32-х битные команды. Начальный загрузчик может загрузить либо 16-битный код (с размером слова 16 бит), либо 32-битный код. Сам загрузчик в ПЗУ должен быть конечно-же 32-х битным, чтобы иметь возможность писать старшие 16 бит (т.е. второй слой).
И кстати, можно в ПЗУ записать обычный 16-битный код в первый слой, а второй слой ПЗУ оставить нулевым. Тогда будет практически полностью 16-битная система (ну если не делать переход на неинициализированный участок ОЗУ), которая должна выполнять любой существующий на данный момент 16-битный код.
Минус лишь в том, что вроде бы процессор адресует 32-битные слова, но адрес слов увеличивается как обычно на 2, т.е. 0,2,4,6,...
вот ЧТО здесь пересылается?Пересылаются одиночные слова ( 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 !!!/
Если первые 64К адресного пространства занимает область векторов
Можно сделать и так, что при выполнении Legacy-команды старшие 16 бит регистра PC не будут модифицироваться, тогда можно под 16-битный процесс отводить любую страницу в 64Кб.
- - - Добавлено - - -
Так будет даже правильнее, когда Legacy-команды не трогают старшие 16 бит любых регистров.
При выполнении Legacy-команды точно также, как при записи старшие 16 бит шины данных содержат нули, старшие 16 бит адреса должны выдавать старшие биты регистра PC.
Lethargeek
14.09.2017, 21:43
Пересылаются одиночные слова ( 16-разрядные ) и регистры инкрементируется на 2.
Вот именно. Только вот какая незадача, по задумке автора 16-битного кода сей фрагмент мог из разных мест вызываться для разных действий, для пересылок как инструкций, так и слов данных. Или даже смешанного куска. Но в 32-битном режиме размер инструкций изменился, а данных - нет.
- - - Добавлено - - -
И кстати, можно в ПЗУ записать обычный 16-битный код в первый слой, а второй слой ПЗУ оставить нулевым. Тогда будет практически полностью 16-битная система (ну если не делать переход на неинициализированный участок ОЗУ), которая должна выполнять любой существующий на данный момент 16-битный код.
Как при этом данные адресуются?
тогда можно под 16-битный процесс отводить любую страницу в 64Кб.Для 16-битных процессов в архитектуре есть специальный режим абсолютной совместимости с PDP-11, поэтому сейчас речь только о 32-битных процессах, в любом месте адресного пространства которых может исполняться легаси-код.
- - - Добавлено - - -
Вот именно. Только вот какая незадача, по задумке автора 16-битного кода сей фрагмент мог из разных мест вызываться для разных действий, для пересылок как инструкций, так и слов данных. Или даже смешанного куска. Но в 32-битном режиме размер инструкций изменился, а данных - нет.Именно так, поэтому полная совместимость невозможна В ПРИНЦИПЕ.
Как при этом данные адресуются?
Также как и раньше. В том-то и идея, что нет разницы ни для 16-битного, ни для 32-битного кода.
Для 16-битных процессов в архитектуре есть специальный режим абсолютной совместимости с PDP-11
Я предлагаю отказаться от режимов. Legacy-команды могут следовать вперемешку с другими командами. Это упростит архитектуру процессора. Несложно будет переделать то, что отреверсили, и долнить это новыми командами.
Legacy-команды могут следовать вперемешку с другими командами.Легаси-команды - это точно такие же 32-разрядные команды, как и все остальные 32-разрядные команды. Абсолютная невозможность полной совместимости 16-разрядного кода с 32-разрядным режимом полностью снимает проблему совместимости. Для 16-разрядного кода - 16-разрядный режим, для 32-разрядного кода - 32-разрядный режим.
Lethargeek
14.09.2017, 22:05
Именно так, поэтому полная совместимость невозможна В ПРИНЦИПЕ.
В ПРИНЦИПЕ возможна, если подумать. Но стоит ли таким путём её добиваться.
Также как и раньше. В том-то и идея, что нет разницы ни для 16-битного, ни для 32-битного кода.
Поясни. Вот раньше был массив, к примеру, из 5 слов, в 16-битном режиме располагались в памяти друг за другом. А как будут в 32-битном располагаться?
Вот раньше был массив, к примеру, из 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-разрядной сможет.
Lethargeek
14.09.2017, 22:08
Легаси-команды - это точно такие же 32-разрядные команды, как и все остальные 32-разрядные команды.
и зачем они тогда нужны как отдельный класс? "упрощение переделки старых кодогенераторов" на вескую причину как-то не тянет, всё равно и новые генрировать
В ПРИНЦИПЕ возможнаПолная совместимость - это когда 16-разрядные и 32-разрядные команды выполняются вперемешку в одном адресном пространстве. Можно ввести 32-разрядную команду: "выполнить следующие Х слов в 16-разрядном режиме", но это не может решить проблему абсолютной адресации, потому что команды из 16-разрядного фрагмента должны иметь доступ к данным за пределами фрагмента.
- - - Добавлено - - -
и зачем они тогда нужны как отдельный класс? "упрощение переделки старых кодогенераторов" на вескую причину как-то не тянет, всё равно и новые генрироватьДругая причина - помочь всем и каждому понять, почему полная совместимость старого двоичного 16-разрядного кода с 32-разрядным адресным пространством - в принципе невозможна.
Lethargeek
14.09.2017, 22:26
Полная совместимость - это когда 16-разрядные и 32-разрядные команды выполняются вперемешку в одном адресном пространстве. Можно ввести 32-разрядную команду: "выполнить следующие Х слов в 16-разрядном режиме",
...и команду для X=1 обозвать префиксом смены разрядности))
команды из 16-разрядного фрагмента должны иметь доступ к данным за пределами фрагмента
это за пределами совместимости (хотя можно запилить сегменты как на пц)))
- - - Добавлено - - -
Другая причина - помочь всем и каждому понять, почему полная совместимость старого двоичного 16-разрядного кода с 32-разрядным адресным пространством - в принципе невозможна.
еще лучше - "сделаем нелепую архитектуру, чтоб все поняли, насколько она нелепа" :v2_wacko:
это за пределами совместимости (хотя можно запилить сегменты как на пц)Существует абсолютная гарантия, что для любой 32-разрядной архитектуры всегда найдётся такой двоичный 16-разрядный код PDP-11, который не будет исполняться в этой 32-разрядной архитектуре так же, как в PDP-11. Эта гарантия делает совершенно бессмысленными любые попытки обеспечить частичную совместимость. Совместимость не бывает частичной - она или есть, или её нет. В случае с двоичным кодом PDP-11 - полная совместимость принципиально невозможна, а частичная - даром не нужна.
- - - Добавлено - - -
Но если речь идёт о полной совместимости на уровне исходных текстов - такая совместимость легко достигается директивой компилятора "включить предупреждения совместимости" - тогда компилятор выделит все строки кода, выполнение которых даст несовместимый результат в 16-разрядном и 32-разрядном режиме.
Например:
CONST = .+2. ; <-- !!! Несовместимо !!!
1$: MOV #36., R0
.TTYOUT
DEC CONST
SOB R0, 1$
HALT
Lethargeek
15.09.2017, 02:51
Существует абсолютная гарантия, что для любой 32-разрядной архитектуры всегда найдётся такой двоичный 16-разрядный код PDP-11, который не будет исполняться в этой 32-разрядной архитектуре так же, как в PDP-11.
да ладно? вот прям красавец pdp настолько ущербнее уродца x86, где шмогли отвиртуалить 16 бит?
Эта гарантия делает совершенно бессмысленными любые попытки обеспечить частичную совместимость.
то есть "раз 10% кода не заработает - нахрен остальные 90%" - так штоле?
Совместимость не бывает частичной - она или есть, или её нет.
еще как бывает, и очень разная - бинарная на уровне железа или оси, на уровне исходников итд
В случае с двоичным кодом PDP-11 - полная совместимость принципиально невозможна, а частичная - даром не нужна.
два необоснованных утверждения
Но если речь идёт о полной совместимости на уровне исходных текстов - такая совместимость легко достигается директивой компилятора "включить предупреждения совместимости" - тогда компилятор выделит все строки кода, выполнение которых даст несовместимый результат в 16-разрядном и 32-разрядном режиме.
а, ну тогда "если речь идёт о полной бинарной совместимости - такая совместимость легко достигается прерыванием привилегированных операций" :)
- - - Добавлено - - -
Ладно, вот какая мысль извратная пришла в голову. Расширяем все регистры до 32 бит. А размер команды и слова данных при работе с памятью автоматически определяться будет по адресу! В первых 64k - слово 16 бит, при чтении расширять нулём до 32 (вариант - в первых и последних 32k, при чтении расширять знаком). Остальные адреса - слово 32 бита, в том числе для выборки команды (на деле все реальные адреса мб выровнены на 4 байта, если так нужно). Ну, там также можно добавлять команд, регистров в новом формате. Биты для формирования флагов тоже от адреса команды зависеть могут. Перенос прерыванием отлавливать еще можно, корректировать регистры для совместимости. Таким образом, любой старый 16-битный код свободно сможет выполняться любым процессом, а при переходе в старшие адреса (если не блокировать переносы) автоматически становится 32-битным.
LeoN65816
15.09.2017, 06:50
Извиняйте, пожалуйста, что лезу в Ваш калашный ряд... ;)
По поводу совместимости, быть может Вам будет интересно (и полезно), это как вариант: посмотрите как в 16-битном 65816 реализована совместимость со старым 8-битным 65(C)02 (https://en.wikipedia.org/wiki/WDC_65816/65802). Правда, в русской википедии налажали с переключением в расширенный (нативный) режим, в даташите все основательно расписано.
помочь всем и каждому понять, почему полная совместимость старого двоичного 16-разрядного кода с 32-разрядным адресным пространством - в принципе невозможна.
Да почему невозможна-то? Если сохранить адресацию слов через 2 (неважно, что при этом процессор будет читать не два байта, а четыре), то какие проблемы-то? Или всех смущает, что при побайтовой адресации нам недоступны старшие 16 бит слова? Так их можно будет адресовать нормальными 32-битными командами.
какие проблемы-то?Как родной 16-разрядный двоичный код из старой операционки попадёт в 32-разрядное адресное пространство только что скомпилированной 32-разрядной программы? Если речь только о 16-разрядных библиотечных модулях, то компоновщик может автоматически превращать их в 32-разрядные на этапе компоновки. Зачем усложнять аппаратуру там, где всё можно решить алгоритмически. Но если речь о запуске оригинальных программ из других операционок - специально для этого у процессора есть режим полной совместимости с PDP-11. Так в чём проблема-то?
Кстати, для избавления 32-разрядного кода от зла абсолютной адресации перемещаемых данных - в числе команд нового процессора может весьма пригодиться команда: ADDR Label,Rx, реализующая командную последовательность: MOV PC, Rx | ADD (PC)+,Rx, но без изменения флагов в PSW.
Зачем усложнять аппаратуру там, где всё можно решить алгоритмически. Но если речь о запуске оригинальных программ из других операционок - специально для этого у процессора есть режим полной совместимости с PDP-11.
Другой режим процессора - это и есть усложнение аппаратуры (по крайней мере самого процессора). По-моему, дискуссия идёт в тупик, я туда не пойду.
Другой режим процессора - это и есть усложнение аппаратурыА как ещё запускать родные программы 16-разрядных операционок? Или полная совместимость с PDP-11 не нужна? Но если всё, что интересует - линковать старые библиотечные модули в компилируемые 32-разрядные программы - зачем городить огород с поддержкой 16-разрядных команд в 32-разрядном режиме, ведь компоновщик без проблем превратит любой ( даже самый несовместимый ) 16-разрядный код в 32-разрядный. Если в линкуемом 16-разрядном коде даже есть вызовы других операционок - компоновщик может без проблем прикомпоновать к программе 32-разрядные обработчики вызовов всех используемых в программе старых операционок.
Такой уровень МЕГА-СОВМЕСТИМОСТИ 32-разрядного и 16-разрядного кода в одной программе - в принципе невозможно получить аппаратно.
Так в чём проблема-то? Почему полная совместимость с PDP-11 как в 16-разрядном, так и в 32-разрядном режимах не удовлетворяет?
- - - Добавлено - - -
Нужно отчётливо понимать, что любое количество 16-разрядных и 32-разрядных процессов могут выполняться ОДНОВРЕМЕННО. В каждом 16-разрядном процессе пользователь получает голую виртуальную PDP-11 с характеристиками, зависящими от конфигурации 16-разрядного сопроцессора. При отсутствии в конфигурации сопроцессора - создание 16-разрядных процессов невозможно.
- - - Добавлено - - -
В принципе - можно предусмотреть создание виртуальных 16-разрядных процессов операционками, содержащими 16-разрядные виртуальные машины. Учитывая, что быстродействие 32-разрядного процессора в 20-100 ( и более ) раз превышает быстродействие реальных процессоров PDP-11 - возможно, есть смысл вообще не заморачиваться аппаратной поддержкой 16-разрядных процессов и с самого начала отдать работу с 16-разрядными процессами виртуальным машинам 32-разрядных операционок.
Тогда можно в некоторых случаях даже не перекомпоновывать старый 16-разрядный код в 32-разрядный, а просто вместо вызова 16-разрядной подпрограммы делать вызов интерпретатора 16-разрядной виртуальной машины с адресом вызываемого 16-разрядного кода в качестве аргумента.
А теперь расскажите мне, как запускаются программы, написанные для RSX-11 - под VMS-11
Нужно отчётливо понимать, что любое количество 16-разрядных и 32-разрядных процессов могут выполняться ОДНОВРЕМЕННО. В каждом 16-разрядном процессе пользователь получает голую виртуальную PDP-11 с характеристиками, зависящими от конфигурации 16-разрядного сопроцессора. При отсутствии в конфигурации сопроцессора - создание 16-разрядных процессов невозможно.
а несколько ядер (два) 16 и 32 неравноправных естественно,а управляемых и отлаженную,
микропрограмму управления этим хозяйтсвом + буфер некий для данных. ) (извиняюсь что встрял).
а несколько ядер (два) 16 и 32 неравноправных естественноНе уверен, что кому-то кроме военных может понадобиться аппаратная поддержка 16-разрядных процессов. В принципе, поддержки 16-разрядных процессов ( и 16-разрядных подпрограмм в 32-разрядных программах ) обычным программным эмулятором PDP-11 в ядре 32-разрядной операционки - за глаза хватит для любых "бытовых" применений.
обычным программным эмулятором PDP-11 в ядре
вот вам верю )))
Lethargeek
15.09.2017, 17:14
А как ещё запускать родные программы 16-разрядных операционок?
http://zx-pk.ru/threads/28074-32-razryadnyj-protsessor-polnostyu-sovmestimyj-s-arkhitekturoj-pdp-11.html?p=928106&viewfull=1#post928106 (например)
зачем городить огород с поддержкой 16-разрядных команд в 32-разрядном режиме, ведь компоновщик без проблем превратит любой ( даже самый несовместимый ) 16-разрядный код в 32-разрядный.
основная проблема не в командах, а в совместности доступа по байтам и по словам
основная проблема не в командах, а в совместности доступа по байтам и по словамНо в том и преимущество компоновщика, что он совершенно точно знает, где в линкуемых библиотеках 32-разрядный код, а где 16-разрядный. Поэтому, прилинковывая 16-разрядную подпрограмму к 32-разрядному коду - компоновщик может или перекомпилировать 16-разрядный код в ПРАВИЛЬНЫЙ 32-разрядный код, или оформить вызов 16-разрядной подпрограммы через системный вызов интерпретатора 16-разрядного кода. В обоих случаях несовместимость полностью исключена.
Но в том и преимущество компоновщика, что он совершенно точно знает, где в линкуемых библиотеках 32-разрядный код, а где 16-разрядный
Насколько я знаю - стандартный линковщик ничего не знает. Основное, что он делает - подставляет адреса (глобальных) символов и корректирует смещения абсолютных адресов. Он вообще ничего ни о каких кодах не знает.
Насколько я знаю - стандартный линковщик ничего не знает.А линковщик C++ хранит OBJ-файлы и библиотечные модули в виде исходников ( точнее - в виде шитого кода со всей информацией из исходника ) и компилирует исходник программы с исходниками всех подключаемых OBJ-файлов и библиотечных модулей ( это нужно для глобальной оптимизации и называется "генерация кода на этапе компоновки" ), поэтому пределов сложности для компоновщика нет, какой сделаем - такой и будет.
какой сделаем - такой и будет
Для начала нужно сделать процессор.
Lethargeek
15.09.2017, 20:58
Но в том и преимущество компоновщика, что он совершенно точно знает, где в линкуемых библиотеках 32-разрядный код, а где 16-разрядный. Поэтому, прилинковывая 16-разрядную подпрограмму к 32-разрядному коду - компоновщик может или перекомпилировать 16-разрядный код в ПРАВИЛЬНЫЙ 32-разрядный код,
как проверить ПРАВИЛЬНОСТЬ без изучения ассемблерного исходника? (что по трудоёмкости почти как переписать)
или оформить вызов 16-разрядной подпрограммы через системный вызов интерпретатора 16-разрядного кода.
да так любой 32-битный процессор с эмулятором pdp-11 можно представлять как "полностью совместимый"
как проверить ПРАВИЛЬНОСТЬ без изучения ассемблерного исходника?Между двоичным кодом и ассемблерным текстом нет принципиального различия. Приведите пример 16-разрядного ассемблерного текста, по коду которого невозможно определить, к каким адресам и с каким размером операнда происходит обращение. Если это возможно определить всегда и для любого 16-разрядного кода - значит не должно быть проблем с автоматической конвертацией этого кода в аналогичный по действиям 32-разрядный код. А если компоновщик обнаружит сомнительные моменты, вроде неочевидной модификации кода, он может вместо перекомпиляции конкретного блока кода - поставить на его место вызов интерпретатора этого же кода.
да так любой 32-битный процессор с эмулятором pdp-11 можно представлять как "полностью совместимый"Если работающая на неком процессоре операционная система позволяет запускать любые программы PDP-11 с точно таким же результатом, как на PDP-11, а архитектура позволяет подключать к шине любые устройства PDP-11, то так ли уж важно, что именно написано на процессоре.
Lethargeek
17.09.2017, 00:38
Между двоичным кодом и ассемблерным текстом нет принципиального различия.
это между машинным дизассемблером и бинарником его нету, а между исходником и бинарником оно есть
Приведите пример 16-разрядного ассемблерного текста, по коду которого невозможно определить, к каким адресам и с каким размером операнда происходит обращение.
выше приводил уже, с пересылкой
Если это возможно определить всегда и для любого 16-разрядного кода - значит не должно быть проблем с автоматической конвертацией этого кода в аналогичный по действиям 32-разрядный код.
это в принципе для многих случаев косвенного доступа невозможно или же технически затруднительно
(поди узнай, что окажется в рантайме в регистре адреса, и человек-то догадается не всегда)
А если компоновщик обнаружит сомнительные моменты, вроде неочевидной модификации кода, он может вместо перекомпиляции конкретного блока кода - поставить на его место вызов интерпретатора этого же кода.
склонен думать, что сомнительных моментов будет настолько много, что в итоге почти всё потребует эмулятора
Если работающая на неком процессоре операционная система позволяет запускать любые программы PDP-11 с точно таким же результатом, как на PDP-11, а архитектура позволяет подключать к шине любые устройства PDP-11, то так ли уж важно, что именно написано на процессоре.
тогда целью должен быть не процессор, а адаптер для подключения устройств pdp к нынешним пк
для многих случаев косвенного доступа невозможно или же технически затруднительно
(поди узнай, что окажется в рантайме в регистре адреса, и человек-то догадается не всегда)Если библиотечный модуль обращается к произвольным внешним адресам - его универсальная работоспособность на всех архитектурах и во всех операционках 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
аппаратная виртуализация Intel позволяет программному эмулятору выполнять эмулируемый код
Там не программная эмуляция - там управляемый проброс ТОГО ЖЕ самого процессора внутрь виртуалки плюс возможности ограничения по функционалу. Никакой программной эмуляции и никакого расширений функционала. Именно поэтому - несколько процентов снижения быстродействия.
blackmirror
17.09.2017, 13:04
Patron, читаю уже 11ю страницу и никак не могу понять что в итоге вы хотите получить:
1) возможность запускать "правильные"(использующие только системные вызовы) 16 разрядные прикладные программы внутри 32х разрядной ОС
2) возможность запустить 16 разрядную ОС или новую 32х разрядную
3) возможность запустить 16 разрядную ОС внутри 32х разрядной
4) возможность запустить несколько 16 разрядных ОС внутри 32х разрядной
5) возможность запускать 16 разрядные ОС внутри 32х разрядных программ, внутри 32х разрядной ОС
?
и никак не могу понять что в итоге вы хотите получить:
Про остальное ничего пока сказать не могу - это уже конкретика (причём конкретика одного блока проца) - и что бы ответить на неё - нужна архитектура в целом и ответ на вопрос - зачем (нам это может понадобиться)? А мы пока ещё далеко в самом начале проекта архитектуры.
Я не знаю, что хочет получить Патрон.
Что хочу получить я - проц, идеологически построенный по принципам (не обязательно всем, но хочу такую же вкусную ортогональную систему команд) моего любимого PDP-11, но без его недостатков, основной из которых - 16-ти битность. Сильно желательно поддержка PDP-11 совместимого режима работы, что бы можно было с минимальными переделками запустить на нём мою любимую же RSX-11M-PLUS (подозреваю так же, что и RT-11 можно будет запустить с минимальными переделками) - что бы с самого начала была доступна кака-никака операционка. Думаю, что после запуска этих операционок проги, которые не лезут напрямую к железу, тоже будут работать :) Наличие режима совместимости позволит так же собрать комп типа PDP-совместимых и при наличии соответствующего железа (типа КЦГД) (может быть в эмуляторе) и запускать проги типа игрушек.
Наличие (правильно спроектированного) 32-битного режима позволит (с бОльшими переделками) запустить RSX-11M-PLUS с большим объёмом ресурсов и создавать (более быстродействующие) программы менее гемморойным способом.
Для чего мне оно? А ни для чего - just for fun :)
- - - Добавлено - - -
И поскольку с моей точки зрения народ в этом топике начал не с того и пошёл не туда - я теперь слежу за ним только краем уха.
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-разрядном режиме.
Нет смысла
Гораздо проще
Как нибудь сам.
Наличие в архитектуре отдельного 32-разрядного процессора
И додумывать за меня не надо - я (пока) вообще не говорил - будет ли это один, будет ли их два, будет ли это аппаратная, будет ли это программная.
Вот руки дойдут (после того, как будут финансы на FPGA и после того как для начала посмотрю сам - чего оно там внутри и сделаю PDP-11 на FPGA) - тогда и буду детали прорабатывать. Когда будет понятно - чего и как умеет платформа реализации.
А может и не дойдут руки - забот хватает и без хобби
Вот руки дойдут (после того, как будут финансы на FPGA и после того как для начала посмотрю сам - чего оно там внутри и сделаю PDP-11 на FPGA) - тогда и буду детали прорабатывать.Но сделать сначала программный эмулятор (на мой взгляд) тоже полезно. Во всяком случае - благодаря данному обсуждению стало гораздо понятнее, какой может быть архитектура 32-разрядного процессора, максимально совместимого с PDP-11.
Если смотреть с точки зрения программного эмулятора, то на первом этапе проще реализовать 32-разрядного "наследника" процессора 1801ВМ2. Без диспетчера памяти, но с раздельными адресными пространствами ( т.е. "модами") системы и пульта. С 32-разрядными легаси-командами, без поддержки 16-разрядного кода. С плоским адресным пространством 4Гб, условно разбитым на страницы по 4Мб, в старшей из которых видно старшие 4Мб моды пульта со страницей ввода-вывода. Если первый блок памяти 512Кб отдать под область векторов и начального стека, то перекомпилированная RT-11 вполне должна нормально работать даже в конфигурации всего с двумя блоками памяти по 512Кб. Правда, ещё какое-то количество отдельного ОЗУ нужно для нормальной работы ПЗУ пульта.
Нет смысла иметь в 32-разрядном процессоре отдельное 16-разрядное ядро для отдельного 16-разрядного режима работы.
Хунта грубиян ! (модераторы такое общение допускают, а это плохо!)
(пусть ка в секте Воланда идёт грубить посмотрим как его там местное армянское радио округлит)
У меня по теме вопрос! Patron, а в чём разница ядро-16 или сопроцессор-16 если средства передачи управления
будут примерно одинаковы? Ядро-16 должно ведь быстрее работать (интеграция,миниатюризация )? То есть софт
то всё равно не поймёт разницы? Вот этот момент мне как не профи не совсем понятен. Тема очень интересная.
а в чём разница ядро-16 или сопроцессор-16 если средства передачи управления будут примерно одинаковы?Разница в том, что при реализации в FPGA проще (на мой взгляд) иметь отдельный эмулятор (например) PDP-11/70, который работает при переключении архитектуры в чистый 16-разрядный режим, и отдельный эмулятор нового 32-разрядного процессора, который работает только в 32-разрядном режиме.
Софт для PDP-11 никогда не поймёт разницы, так же, как он не понимает разницы при запуске в программном эмуляторе PDP-11 под Windows. Разница есть только с точки зрения сложности разработки аппаратуры - какие функции есть смысл реализовать в FPGA 32-разрядного процессора, какие - в FPGA 16-разрядного сопроцессора, а какие - чисто программно.
Но сделать сначала программный эмулятор (на мой взгляд) тоже полезно
Не совсем уверен. На мой (пока почти никакой) взгляд программирование FPGA - это всё таки не классическое программирование и если чем и поможет эмулятор - отладкой софта на этапе, когда FPGA варианта ещё нет. В принципе на нём можно прикинуть быстродействия того или иного архитектурного решения - но если ты уверенно представляешь себе - а как оно будет ложиться на FPGA.
- - - Добавлено - - -
Хунта
Да да, меня Хунтой зовут
если чем и поможет эмулятор - отладкой софта на этапе, когда FPGA варианта ещё нетБез простого эмулятора архитектуры и системы команд - даже стартовое ПЗУ сделать трудновато, потому что вряд ли реально программировать, когда для отладки скомпилированного кросс-системой кода его надо каждый раз грузить в голое железо или как-то запускать в симуляторе HDL. А портировать операционку без эмулятора - это ( на мой взгляд ) вообще фантастика.
Проще представить успешную реализацию в железе архитектуры, для которой уже есть эмулятор и солидный набор портированного ПО, чем успешную реализацию архитектуры, на которой ни разу не выполнялась ни одна программа и непонятно, как их писать и отлаживать.
Lethargeek
17.09.2017, 21:02
Если библиотечный модуль обращается к произвольным внешним адресам - его универсальная работоспособность на всех архитектурах и во всех операционках PDP-11 также не гарантирована. Если библиотечный модуль не осуществляет косвенных обращений за пределы собственного сегмента данных -
- то всё равно никакой гарантии дать нельзя!
такие обращения будут осуществляться 32-разрядным кодом точно так же, как и 16-разрядным.
что такое "точно так же", конкретней можно?
принудительно всегда по 16 бит? поломается модифицируемый код!
всегда по 32 битным словам? поломаются побайтовые проходы!
- то всё равно никакой гарантии дать нельзя!Когда по условию задачи заранее известно, что код обращается к данным ( например - к строке байтов ) и известен размер обращения ( из кода команды ) - возможность обращения к тем же данным с тем же размером гарантирована.
что такое "точно так же", конкретней можно?Точно так же - значит с таким же размером. Если 16-разрядный код обращается к байту, то и 32-разрядный обращается к байту, если 16-разрядный код обращается к 16-разрядному слову, то и 32-разрядный код обращается к 16-разрядному слову.
принудительно всегда по 16 бит? поломается модифицируемый код!
всегда по 32 битным словам? поломаются побайтовые проходы!Модифицируемый код точно не поломается, если его не использовать. Приведите пример библиотечного модуля с самомодифицируемым кодом - вряд ли такие вообще есть. А ведь чтобы попасть в адресное пространство 32-разрядного процесса - 16-разрядный код должен быть прилинкован к 32-разрядной программе из 16-разрядной библиотеки.
Под модифицируемым кодом имеется в виду код, изменяющий первое слово команды, а не второе или третье. Если запись идёт во второе или третье слово команды - такой "модифицируемый код" без проблем автоматически превращается в 32-разрядный.
Байтовые обращения к данным не могут поломаться, потому что и 16-разрядная, и 32-разрядная архитектуры обращаются к 8-разрядным и 16-разрядным данным одинаково. Разница только в обращении к коду. У 16-разрядного кода обращение к коду 16-разрядное, а у 32-разрядного кода обращение к коду 32-разрядное.
Пара мыслей на тему виртуализации PDP-11 в 32-разрядном режиме.
32-разрядная архитектура вводит дополнительные 8 номеров регистров. При обсуждении виртуализации эти дополнительные регистры удобно называть RR0..RR7. Переход в режим виртуализации PDP-11 возможен только из 32-разрядного режима. Для этого надо загрузить в RR7 адрес таблицы виртуализации и выполнить Extended Legacy команду DO16 ( это может быть легаси-команда IOT с установленным битом Extended в старшем слове 32-разрядного кода команды ). При переходе в режим 16-разрядной виртуализации в PSW устанавливается специальный бит VM, позволяющий обрабатывать реальные прерывания с возвратом в режим виртуализации. В таком случае, при входе в прерывание - в стеке вместо 32-разрядного PC сохраняется адрес таблицы виртуализации. Логично, если в начале таблицы виртуализации будет содержаться 32-разрядный код команды JMP @(PC)+, а в следующей 32-разрядной ячейке таблицы будет сохранён адрес следующей команды после DO16. Тогда, если в ходе обработки прерывания будет сброшен флаг VM в сохранённом значении PSW - выход из прерывания приведёт к выходу из виртуализации в прерванном коде. Это может быть полезным при зависании 16-разрядного кода.
В режиме виртуализации младшие слова регистров RR выполняют роль 16-разрядных R0..R7, старшее слово RR6 играет роль 16-разрядного PSW, а в старшем слове RR7 содержится код текущей исполняемой команды. При выходе/вылете из режима виртуализации по любой причине - выполнение кода 32-разрядного режима продолжается с команды, следующей за DO16, а содержимое RR6 и RR7 остаётся таким же, каким было в момент выхода/вылета из виртуализации. Судьба содержимого других регистров зависит от флагов в таблице виртуализации, в которой также может сохраняться содержимое RR0..RR6, имевшееся на момент вызова.
- - - Добавлено - - -
Если бит VM будет установлен в загружаемом PSW из вектора прерывания, а сохраняемое значение PSW не содержит установленного бита VM - то для возврата из 16-разрядного обработчика в прерванный 32-разрядный код - в начале таблицы виртуализации, адресуемой вторым 32-разрядным значением из вектора прерывания - должна находиться команда RTI. Тогда любой выход/вылет из 16-разрядного обработчика реального прерывания приведёт к возврату в прерванный 32-разрядный код.
Если бит VM будет установлен в загружаемом PSW из вектора прерывания и сохраняемое значение PSW также содержит установленный бит VM ( т.е. выполнение 16-разрядного кода было прервано реальным прерыванием с переходом в 16-разрядный обработчик ) - для возврата из 16-разрядного обработчика в прерванный 16-разрядный код - в начале таблицы виртуализации, адресуемой вторым 32-разрядным значением из вектора прерывания - также должна находиться команда RTI.
- - - Добавлено - - -
Но в принципе - обрабатывать реальные "32-разрядные" прерывания виртуализованным 16-разрядным кодом - это уже за гранью добра и зла, поэтому проще запретить установку бита VM из вектора прерывания. Тогда для установки бита VM останутся только два способа - команда DO16 и команды RTI / RTT, загружающие в PSW содержимое с битом VM. Разница между этими способами в том, что при выполнении команды DO16 процессор сохраняет значение PC по смещению +4 от начала таблицы виртуализации ( и если надо - сохраняет в таблице виртуализации содержимое RR0..RR5 ), а при выполнении команд RTI / RTT содержимое таблицы виртуализации не меняется.
- - - Добавлено - - -
Всего возможны четыре уровня сложности виртуализации PDP-11:
1. Виртуализация PDP-11 невозможна. Команда DO16 вызывает Trap_10. Бит VM в PSW всегда нулевой.
2. Виртуализация приложений PDP-11. Без поддержки виртуальной страницы ввода-вывода и виртуальных прерываний.
3. Виртуализация 16-разрядной архитектуры PDP-11. С поддержкой виртуальной страницы ввода-вывода и виртуальных прерываний.
4. Виртуализация 22-разрядной архитектуры PDP-11. С поддержкой виртуальной страницы ввода-вывода, виртуальных прерываний и виртуального диспетчера памяти.
Реализация виртуализации PDP-11 максимального уровня сложности - потребует не меньше ресурсов FPGA, чем требуется (например) для полноценной эмуляции в FPGA чего-то вроде PDP-11/70 со всеми контроллерами эмулируемых внешних устройств. В идеале - стандарт должен предлагать рабочие модели всех четырёх вариантов виртуализации, а уже пользователь будет решать, какой из вариантов реализовать в железе.
blackmirror
18.09.2017, 23:22
Lethargeek, до меня дошло как командами "условного" pdp32 выполнять код для "условного" pdp16. Делается три блока:
1) "pdp16" в котором лежит код и данные эмулируемой системы.
2) "pdp32" из которого осуществляется выборка кода pdp32
3) "emu32" в котором будет жить "переводчик"
Каждому слову(16бит) в блоке pdp16(или байту если команды могут начинаться с нечётных адресов) будет соответствовать слово(32бита) в блоке pdp32. Изначально слова в блоке pdp32 обнулены и попытка их выполнения вызывает исключение, по которому будет вызван переводчик из блока emu32. Переводчик смотрит какая команда pdp16 должна была быть выполнена, помещает её эквивалент в блок pdp32 и возвращается из исключения. Далее будет выполнен эквивалент требуемой команды, после чего будет предпринята попытка выполнения следующей.
Для поддержки самомодифицирующегося кода при записи байта/слова в блок pdp16 соответствующее слово из блока pdp32 будет обнуляться, и если исполнение дойдёт до такой команды, то снова будет вызван переводчик. Или можно прицепить ко всем связанным ячейкам(слово pdp16 - слово pdp32) признак "был доступ"(еще одна область памяти), устанавливающийся при записи слова в блок pdp16 и сбрасываются при записи соответствующего слова в блок pdp32(переводчиком), ну а при выполнении исключение будет вызываться в зависимости от даннного признака.
Если некоторые команды pdp16 не имеют простых эквивалентов среди команд pdp32, то на её место просто ставится вызов подпрограммы. Если ситуация совсем запущенная и мы хотим эмулировать что-то сильно непохожее на pdp32, то либо везде ставим вызовы подпрограмм или на каждый байт/слово просто выделяем больше(2,4,8) слов в блоке pdp32, чтобы в такой блок влезал эквивалент большинства эмулируемых команд.
При наличии нормального механизма виртуальной памяти для блока pdp32 нужно будет зарезервировать адреса, а выделять память только для тех страниц, код из которых реально исполняется. Ну а когда памяти становится маловато, страницы блока pdp16 можно выгружать, а перевод из блока pdp32 просто грохнуть, поскольку потом мы его легко восстановим.
до меня дошло как командами "условного" pdp32 выполнять код для "условного" pdp16.Но 16-разрядный код может быть вызван из 32-разрядного для каких-то действий в интересах 32-разрядного кода. Когда взаимодействие 32-разрядного и 16-разрядного кода идёт только через регистры - всё достаточно просто. А как должен выглядеть (например) вызов 16-разрядной функции STRLEN, получающей в R0 адрес строки и возвращающий её длину, если строка расположена в произвольном месте 32-разрядного адресного пространства.
В случае виртуализации - перед вызовом 16-разрядного кода создаётся таблица виртуализации, через которую осуществляется мапинг 16-разрядных обращений в 32-разрядное адресное пространство и где помимо основного 16-разрядного сегмента, содержащего код 16-разрядной функции - можно также задать окна для внешнего чтения и внешней записи. В таком случае, если виртуализованный код осуществляет чтение за пределами диапазона адресов основного сегмента - проверяется попадание чтения в окно внешнего чтения и если попадание есть - обращение транслируется в основное 32-разрядное пространство через базу из таблицы виртуализации и смещение в окне обращения. За счёт такого подхода 16-разрядная функция STRLEN может определить длину строки, находящейся в любом месте 32-разрядного адресного пространства.
В реальной жизни такое вряд ли случится и главной целью виртуализации приложений будет запуск целых 16-разрядных программ из различных операционок PDP-11, но механизм виртуализации при этом останется тем же самым.
Lethargeek
19.09.2017, 00:53
Когда по условию задачи заранее известно, что код обращается к данным ( например - к строке байтов ) и известен размер обращения ( из кода команды ) - возможность обращения к тем же данным с тем же размером гарантирована.
и ОТКУДА же это может без прокомментированного исходника быть известно?
где ГАРАНТИЯ, что к одной и той же структуре в памяти нет обращений И по байтам, И по словам?
где ГАРАНТИЯ, что содержимое структуры - 16-битные числа, а не опкоды (и не опкоды с числами вперемешку)?
Точно так же - значит с таким же размером. Если 16-разрядный код обращается к байту, то и 32-разрядный обращается к байту, если 16-разрядный код обращается к 16-разрядному слову, то и 32-разрядный код обращается к 16-разрядному слову.
а если 16-битным код обращался к 16-битным старым ОПКОДАМ (которые стали 32-битными) и как об этом компоновщик должен догадываться?
а если хуже - один код из разных мест вызывается для обращения И к опкодам, И к 16-битным данным (см. мой пример с пересылкой)?
Модифицируемый код точно не поломается, если его не использовать. Приведите пример библиотечного модуля с самомодифицируемым кодом - вряд ли такие вообще есть.
"вряд ли" не считается за ГАРАНТИЮ, а контрпримера и гипотетического достаточно
Под модифицируемым кодом имеется в виду код, изменяющий первое слово команды, а не второе или третье. Если запись идёт во второе или третье слово команды - такой "модифицируемый код" без проблем автоматически превращается в 32-разрядный.
нет, имеется в виду перезапись произвольного куска в памяти, в который после может выполнение перейти
Байтовые обращения к данным не могут поломаться, потому что и 16-разрядная, и 32-разрядная архитектуры обращаются к 8-разрядным и 16-разрядным данным одинаково. Разница только в обращении к коду. У 16-разрядного кода обращение к коду 16-разрядное, а у 32-разрядного кода обращение к коду 32-разрядное.
еще раз: КАК понять, что обращение было к коду? еще раз: где ГАРАНТИЯ, что команда обращается ТОЛЬКО к коду?
- - - Добавлено - - -
blackmirror, а вот это может и заработать, но не проще ли тогда уж выполнять pdp16 блок напрямую
- - - Добавлено - - -
пора тему переименовывать в "эмуляцию pdp-11 на каком-нибудь 32-битном процессоре" :)
а если 16-битным код обращался к 16-битным старым ОПКОДАМ (которые стали 32-битными) и как об этом компоновщик должен догадываться?
а если хуже - один код из разных мест вызывается для обращения И к опкодам, И к 16-битным данным?Просмотрите исходники всех библиотек и найдите хотя бы один реальный пример кода, который не может быть автоматически перекомпилирован из 16-разрядного в 32-разрядный. В теории такая ситуация возможна, но в возможность встретить её в реальной подпрограмме из реальной библиотеки поверить трудно.
Patron, похоже, что вы говорите о реальном и существующем ПО, а
Lethargeek, о абстрактном )
Таким образом один из вас не видит возможности сбоя, а второй настаивает на абстрактной вероятности сбоя выполнения. Нужен универсальный описанный и разъяснённый метод который гарантирует защиту от сбоя,
ведь будет обидно если аппаратура будет иметь дырку(?) на уровне процессора - это не допустимо в любом случае.
пора тему переименовывать в "эмуляцию pdp-11 на каком-нибудь 32-битном процессоре"
Вот фрагмент исходного кода реализации команд RTI / RTT в микропрограммном эмуляторе, известном как "процессор J11":
.BIN
RTI-RTT: ; Break out RTI and RTT.
=10********0
PLA0 [^0 111 111, ^0 000 000 000 000 X10]
ARI.W [SP], ; Relocate SP in current mode and increment by two.
ODD TRAP, ; Must be a word address.
LD MMR1 ; Record change in MMR1.
RD.W [PC] ; Load PC. MMR2 still has PC if abort.
JKM [RTx_KERNEL] ; Jump around special processing
=0*1***** ; Force abort to ROM[040].
ARI.W [SP], ; Relocate SP again and pop.
LD MMR1 ; Again record the change for MMU.
RD.W [RF] ; Read new PS data
LBIC.B [340,RF] ; Priority is cleared out
=0*1***** ; Force abort to ROM[040].
LLSW.B [370,RE] ; Setup mask to save old modes <15:11>
LLD.B [340,RE] ; Also save old priority information
AND.W [RE,PS] ; Clear out all but <15:11> and <7:5>
BIS.W [RF,PS], ; Build new PS information
NAF/RTx_CONVERGE ; Go and update control chip PS
RTx_KERNEL:
RD.W [PS] ; Kernel mode directly copys input
RTx_CONVERGE:
OUTS [PSW, PS], ; Update Control chip PS<7:4>, interrupt
; priority and T-bit.
Если J11, написанный на уродском ассемблере J11 - это процессор с архитектурой PDP-11, то эмулятор ДВК, написанный на C++ - ничем не хуже.
Настоящие процессоры, не являющиеся внутри себя программными эмуляторами - встречались только в ранние годы PDP-11. Даже один из старых и известных процессоров PDP-11 -- LSI-11 - это программный эмулятор, в который можно (методом перетыкания ПЗУ) загрузить программу, реализующую любую систему команд.
Если переписать исходный код J11 с ассемблера J11 на ассемблер Intel, но сохранить все сигналы и тайминги внешней шины Q-Bus неизменными - такой вариант процессора J11 останется "процессором с архитектурой PDP-11" или нет?
Если ДА, то учитывая, что подключение Q-Bus к 32-разрядному процессору возможно только через адаптер - какая разница, что находится с другой стороны адаптера, если со стороны Q-Bus оно является "процессором с архитектурой PDP-11".
на уродском ассемблере J11
Добро пожаловать в микропрограммирование. Примерно тоже самое, что делается в FPGA
Если переписать исходный код J11 с ассемблера J11 на ассемблер Intel, но сохранить все сигналы и тайминги внешней шины Q-Bus неизменными
Удачи
Даже один из старых и известных процессоров PDP-11 -- LSI-11 - это программный эмулятор, в который можно (методом перетыкания ПЗУ) загрузить программу, реализующую любую систему команд.
LSI-11 программно-аппаратный эмулятор. Декодер команд там зашит в микросхему. Максимум что сможете - слегка "перемешать" систему команд
Добро пожаловать в микропрограммирование.Мик опрограмма - это обычная программа, команды которой выполняются одна за другой.
Примерно тоже самое, что делается в FPGAПримерно то же самое ( последовательное выполнение команд ) делается в микроконтроллере. FPGA - это вентильная матрица, на которой можно реализовать как настоящий процессор, реализующий архитектуру на схемной логике, так и микроконтроллер, реализующий архитектуру на программируемой логике ( т.е. пошагово интерпретирующий микропрограмму для выполнения каждой команды эмулируемой архитектуры ).
- - - Добавлено - - -
УдачиУже сделано (http://zx-pk.ru/threads/25252-adapter-shiny-mpi-dlya-emulyatora-dvk-1.html?p=809912&viewfull=1#post809912).
По ссылке - две потактово идентичных модели процессора 1801ВМ1, одна из которых сделана из HDL-исходника процессора, путём конвертации его в C++, а другая написана, как обычная эмулирующая программа.
Можно запустить обе модели и убедиться в полной идентичности их работы с шиной Q-Bus с точностью до полутакта.
Какая же из этих моделей имеет большее право называться "настоящим процессором с архитектурой PDP-11"..
Уж скоро год как,
А процессора всё нет...
Ария Германна.
Уж скоро год как,
А процессора всё нет...Да что там процессора, даже новой версии Unix для ДВК-2 нет, потому что разработка эффективного оптимизирующего кросс-компилятора C++ для PDP-11 на базе LLVM застряла на полдороге. Но ария про компилятор ещё беспощаднее арии про процессор, поэтому лучше отдохнём ещё годик.
разработка эффективного оптимизирующего кросс-компилятора C++ для PDP-11
что это за Юникс которому С++ нужен?
что это за Юникс которому С++ нужен?
Правильный вариант фразы - Это программисты такие, которым С++ нужен.
что это за Юникс которому С++ нужен?Там конечно же и чистый 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
Хммм...
"Для примера - небольшая программа на C++ и результат её компиляции:"
Чем будет отличаться от эквивалентной "C"-программы ? При идентичных опциях компиляции и в этом же компиляторе но только с-режиме.
Можете привести результат компиляции ?
При идентичных опциях компиляции и в этом же компиляторе но только с-режиме.Никогда не запускал CLang в C-режиме (можете это сделать с приведённым исходником самостоятельно), но подозреваю, что с точки зрения стандарта C исходник может быть синтаксически некорректным. Собственно потому (главным образом) я и использую для C-программирования только C++, что там более адекватный (на мой взгляд) синтаксис, чем в нативном C.
Можете привести результат компиляции ?С или C++ - это фронтенд, он превращает исходник в байткод, а потом уже ассемблер (бэкенд) компилирует этот байткод в код целевой машины. Если C-фронтенд не обидится на синтаксис исходника C++, то результирующий байткод вряд ли будет другим, а значит - результат последующего превращения байткода в код целевой машины будет аналогичным.
Ок. Я не хочу "Святойвойны", но данный пример не говорит о тех или иных преимуществах с++ относительно С.
тк компиляция сего кода может быть идентична до "запятой". в частности openwatcom создаёт один и тот же исполняемый код.
ИМНО использовать С++, утверждая что он создаёт более оптимизированный код , чем просто С, не есть правильно.
Собственно "extern "C" говорит что "компилятор должен" компилировать сей текст как "язык С".
Другими словами Вы говорите что пишете на С++, а по факту пишете на чистом С.
И это как то не вяжется с утверждением " но С++ без использования классов и прочих "апгрейдов" при равной эффективности настолько удобнее просто C, что все C-программы я пишу только на C++"
ПС: Конечно в других частях программы Вы возможно и используете особенности языка С++, но приведённый пример явно не удачен для "демонстрации" плюсов языка С++.
Мож я что то не так понял ?
Мож я что то не так понял ?Результат компиляции получается одинаковым. Удобство C++ в синтаксисе, который лично мне нравится больше. Ну и возможность задавать в C++ дефолтные значения для полей динамически создаваемых структур - тоже радует.
Собственно "extern "C" говорит что "компилятор должен" компилировать сей текст как "язык С".
что-то мне помнится что это всего лишь указывает компилеру что ненадо извращать имена функций в результирующем obj как это принято делать в c++ и используется это исключительно для того чтоб obj генеренный "С" компилятором мог вызвать эту функцию без изменения в исходнике на "С" имени вызываемой функции по извращенческой схеме принятой в с++
- - - Добавлено - - -
про llvm интересно, на сколько я понимаю для написания крутого оптимизатора нужно четко представлять какие операции возможны в исполнителе для которого этот оптимизатор пишется... а так как llvm писался с учетом 32bit процессоров (да еще и не конкретного проца типа "cyrix 486sx25 rev32.22") то он оптимизирует с использованием каких-то общих для всех 32bit cpu операций а потому будет всегда отставать от таких компилеров типа open watcom. Но еще интереснее дело обстоит с pdp-11 учитывая что он довольно сильно отличается от "среднего 32bit" процессора... неужели есть шанс сделать лучше оптимизацию чем в древнем компиляторе на котором unix и был изначально скомпилен?
неужели есть шанс сделать лучше оптимизацию чем в древнем компиляторе на котором unix и был изначально скомпилен?
Единственный шанс сделать лучшую оптимизацию - проанализировать, на какие низкоуровневые (для языка) но всё ещё высокоуровневые (для процессора) операции можно странслировать исходный код - а потом оптимизировать ПРОЦЕССОР под эти операции :) Насколько я себе представляю, по этому пошли разработчики (группа под руководством Вирта) процессора для рабочей станции Lilith и разработчики (наши) процессора Кронос
неужели есть шанс сделать лучше оптимизацию чем в древнем компиляторе на котором unix и был изначально скомпилен?
Шанс есть!
Видел года 2 назад порты шланга под 16-ти битные процы. Можно погуглить
clang msp430
:-) clang DCPU-16
8bit clang avr
а чем gcc не устраивает?
неужели есть шанс сделать лучше оптимизацию чем в древнем компиляторе на котором unix и был изначально скомпилен?Если речь идёт о компиляции Unix для машин с 64К ОЗУ, где борьба идёт за каждый байт - имеющиеся (для PDP-11) компиляторы C практически непригодны, потому что оптимизируют код очень слабо. Главная (по количеству бездарно потраченных компилятором байтов) проблема - наличие у функций прологов и эпилогов, а также использование стека для передачи параметров и создания локальных переменных. LLVM позволяет выделить пул временных регистров ( например для PDP11 - R0, R1, R2 ) и тогда первые три параметра вызова функции будут передаваться не в стеке, а в этих регистрах. Если же параметров у функции меньше (или их вообще нет) - свободные временные регистры будут автоматически использоваться для хранения локальных переменных. Когда исходник состоит из большого количества небольших функций с малым числом параметров - даже такая простенькая оптимизация сокращает объём генерируемого кода чуть ли не вдвое.
Проще говоря - есть реальный шанс сделать компилятор, который для базового ядра Unix уменьшит объём генерируемого кода в разы (по сравнению с изначальным).
не большой оффтоп:
openwatcom также поступает: по максимуму использует регистры для передачи параметров, а что не помещается то идет через стек. Докучи это "поведение" компилятора можно "переопределить". Жалко что он только для интел и поверпс
"Многие спрашивали, Windows написана на C или C++. Ответ такой: несмотря на объектно-ориентированный дизайн NT, как и большинство ОС, Windows почти полностью написана на C! Почему? Потому что C++ увеличивает потребление памяти и привносит накладные расходы на выполнение кода. Даже сегодня скрытые затраты на выполнение кода C++ могут удивить, но ещё в 1990-х, когда память стоила около $60/МБ (да… $60 за МЕГАБАЙТ!), скрытые затраты на vtables и прочее были значительными. Кроме того, затраты на косвенное обращение к виртуальным методам и разыменование объектов в то время могли привести к очень значительным потерям производительности и масштабированию кода C++"
Насколько мне известно, ядро и системные библиотеки всех широко распространенных ОС написаны на С. Linux, *BSD, Windows, MacOSX. Во многом из-за того, что у них у всех в разностепени, но корни идут от UNIXa Кернигана и Ричи.
У Windows корни не из Unix-а - от слова совсем
CodeMaster
23.08.2018, 09:10
У Windows корни не из Unix-а - от слова совсем
Ну, как бы да:
Для разработки ОС NT фирма Microsoft пригласила группу специалистов из компании DEC во главе с Дэвидом Катлером, обладающую опытом создания многозадачных операционных систем, таких как VAX/VMS и RSX-11. Некоторое сходство, отмеченное между внутренними архитектурами Windows NT и ОС семейства VMS, дало основания обвинить вновь принятых сотрудников Microsoft в краже интеллектуальной собственности DEC.
Но и они же наверняка не C++ писаны. Ещё одной причиной почему Windows NT на С возможно является это:
Переносимость NT была одной из её первоочередных задач ... В качестве ОС высокой переносимости при разработке NT были взяты за пример ОС Unix и Mach.
Вряд ли тогда существовали надёжные и проверенные компиляторы C++ под все интересующие платформы.
Вряд ли тогда существовали надёжные и проверенные компиляторы C++ под все интересующие платформы.
Наверняка. Но приведённая мной цитата - от сотрудника MS. В статье (она про новую версию cmd.exe и инфраструктуру консольных приложений) ещё говорится о том, что сейчас они постепенно переписывают код под C++ - но потому, что стоимость этого варианта (по ресурсам) стала ниже, чем во времена началаписания windows.
Учитывая количество доступных ресурсов на процах семейства PDP-11 - врят ли писание на C++ сильно взлетит. А С - он вообще делался с прицелом и на основе PDP-11, так что можно считать (классические компиляторы) своеобразным макро-ассемблерами.
Мне приходилось восстанавливать текст С-шных модулей из объектных - я после компиляции полученного текста на С получал такой же объектный файл - с точностью до бита.
Почему C-подмножество C++ это "С здорового человека" - небольшой пример.
Допустим, в уже написанной программе есть функция LF(), выводящая на экран перевод строки, и надо модифицировать программу, добавив аналогичную функцию с числовым аргументом, задающим количество выводимых LF.
На С++ есть два варианта решения задачи: 1) добавить вторую функцию, принимающую числовой аргумент; 2) модифицировать исходную функцию, добавив числовой аргумент со значением по умолчанию 1.
void LF( int n = 1 ) { while(n--) printf "\012"; }
На C второй вариант точно не прокатит - в стандарте C дефолтные значения параметров вызова не предусмотрены.
Почему C-подмножество C++ это "С здорового человека" - небольшой пример
Потому что есть фундаментальные свойства языка, а есть синтаксический сахар. Дефолтные значения - пример синтаксического сахара.
И если добавить такие конструкции (удобства) в С - С++ окажется в ещё большем проигрыше.
И если добавить такие конструкции (удобства) в С - С++ окажется в ещё большем проигрыше.О каком "проигрыше" речь, когда исходники обоих стандартов компилирует один и тот же компилятор, создающий из обоих вариантов один и тот же код, а разница только в удобстве синтаксиса у варианта C++.
C-подмножество C++ - это и есть то самое добавление нормальной функциональности в кривоногий синтаксис ванильного C, без которого о нормальном программировании говорить сложно.
Но помимо этого - при C-программировании на C++, появляется возможность использовать и некоторые простые "плюсы" расширенного стандарта. Хороший пример - задание начальных значений полей структур.
Вариант ванильного C:
struct s {
int one;
int two;
};
struct s *pS1 = (struct s*) malloc( sizeof(s) );
(*pS1).one = 1;
(*pS1).two = 2;
struct s *pS2 = (struct s*) malloc( sizeof(s) );
(*pS2).one = 1;
(*pS2).two = 2;
Вариант здорового C ( т.е. C++ ):
struct s {
int one;
int two;
s(): one(1), two(2) {}
};
struct s *pS1 = new s;
struct s *pS2 = new s;
когда исходники обоих стандартов компилирует один и тот же компилятор
Поделитесь компилятором с C++ на PDP-11?
Поделитесь компилятором с C++ на PDP-11?Речь о кросс-компиляторе для Windows на базе LLVM. Для Windows, потому что (как мне показалось) на практике - Visual C++ компилирует гораздо эффективнее LLVM, вот почему проекты на базе LLVM выгоднее всего собирать не в среде LLVM, а под Windows в Visual C++.
Речь о кросс-компиляторе для Windows
Вот когда у Вас будет компилятор С++ для PDP-11 - тогда и продолжим разговор об удобстве и эффективности.
А пока мне удобней писать на Macro-11 с набором макросов для структурированного программирования.
Вот когда у Вас будет компилятор С++ для PDP-11 - тогда и продолжим разговор об удобстве и эффективности.Удобство синтаксиса не зависит от реализации - у "здорового C" синтаксис гораздо удобнее, чем у ванильного, а при компиляции одинаковых программ - код получается одинаковым.
Можно внимательнее рассмотреть пример с начальными значениями полей структур. Возможно это не бросается в глаза, но нормальный оптимизирующий компилятор сгенерит из обоих исходников одинаковый код - разница будет только в том, что у "здорового C" в исходнике нет ручных присваиваний значений полям после создания каждой структуры - компилятор вставит нужный код сам, воспользовавшись информацией из описания структуры.
а при компиляции одинаковых программ - код получается одинаковым.
Вот когда у Вас будет компилятор С++ для PDP-11 - тогда и продолжим разговор об удобстве и эффективности.
А пока это рассуждение на тему - сколько ангелов уместиться на конце иглы. Нет компилятора под PDP-11 - о чём рассуждать?
Нет компилятора под PDP-11 - о чём рассуждать?Не рассуждать, а рассказывать. Что есть два варианта языка C - менее удобный из ванильного стандарта и более удобный из C-подмножества стандарта C++.
Вы уже писали на удобном на PDP-11?
Вы уже писали на удобном на PDP-11?В смысле? Речь всю дрогу идёт о кросс-компиляторе для Windows, который позволит сильно уменьшить объём кода при компиляции для ДВК-2 исходников LSX, переписанных на "правильный C" (т.е. С-подмножество C++).
Ну то есть, как я и сказал - ничего ещё для PDP-11 нет и речь идёт о количестве ангелов. Далее - не интересно.
Ну то есть, как я и сказал - ничего ещё для PDP-11 нетЭто и надо было понять с самого начала и не разводить флуд.
не разводить флуд.
Флуд - были Ваши рассуждения - что компилятор С++ лучше, когда компилятора нет.
shurik-ua
24.08.2018, 19:59
оффтоп:
https://habr.com/company/badoo/blog/420407/
Флуд - были Ваши рассуждения - что компилятор С++ лучшеЧитайте внимательнее - речь изначально шла о том, что стандарт C++ включает в себя синтаксически улучшенный вариант языка C, поэтому некоторым (включая меня) удобнее писать C-программы на этом "правильном C". Т.е. речь не про то, что у C++ компилятор лучше, а про то, что синтаксис удобнее. Что же до генерации кода, то по определению - для любого алгоритма существует единственное оптимальное отображение в процессорный код, поэтому чем ближе результат компиляции некого конкретного алгоритма любым компилятором с любого языка к такому оптимальному процессорному коду - тем лучше компилятор. От компилируемого языка это зависит лишь в той степени, насколько просто реализовать для этого конкретного языка оптимальную компиляцию.
Моя практика реальной разработки компилятора для С-подмножества C++ однозначно говорит за то, что для C-подмножества C++ это ничуть не сложнее, чем для ванильного C.
Моя практика реальной разработки компилятора для С-подмножества C++ однозначно говорит за то, что для C-подмножества C++ это ничуть не сложнее,
потому что разработка эффективного оптимизирующего кросс-компилятора C++ для PDP-11 на базе LLVM застряла на полдороге.
Да да, видно
Да да, видноОб том и речь. Нет разницы, какой вариант C компилируется, "ванильный" или "правильный" - архитектура LLVM настолько заточена под современные реалии, что сделать на базе LLVM нормальный кросс-компилятор для PDP-11 весьма непросто.
Для примера. Самый простенький и невинный (по затратам на преодоление) затык с LLVM возникает из-за того, что весь движок LLVM построен в априорном предположении, будто индексная адресация выгоднее автоинкрементной.
Чтобы заставить LLVM использовать автоинкрементную адресацию в нулевом базовом блоке - нужно изменить относительно немного кода компилятора и результат компиляции такой:
extern "C" void post_5ac( int x, int *pi16 )
{
*pi16++ = x;
*pi16++ = x;
*pi16++ = x;
}
.globl post_5ac ; -- Begin function post_5ac
post_5ac: ; @post_5ac
; BB#0: ; %entry
Mov R0, (R1)+
Mov R0, (R1)+
Mov R0, (R1)
Return
; -- End function
Но чтобы заставить LLVM использовать автоинкрементную адресацию в нескольких базовых блоках подряд - нужно полностью переделать весьма большой кусок компилятора, на что у меня пока запала нет. А без этого результат плачевен:
extern "C" int post_6a( int x, int *pi16 )
{
x |= *pi16++;
x |= *pi16++;
x |= *pi16++;
if( !x )
{
x += *pi16++;
x += *pi16++;
x += *pi16++;
}
else
{
x -= *pi16++;
x -= *pi16++;
x -= *pi16++;
}
return x;
}
.globl post_6a ; -- Begin function post_6a
post_6a: ; @post_6a
; BB#0: ; %entry
Mov R1, R2
BiS (R2)+, R0
BiS (R2)+, R0
BiS (R2)+, R0
Tst R0
BEq .LBB0_2
; BB#1: ; %if.else
SUB (R2), R0
SUB 8(R1), R0
SUB 10(R1), R0
Br .LBB0_3
.LBB0_2: ; %if.then
ADD (R2), R0
ADD 8(R1), R0
ADD 10(R1), R0
.LBB0_3: ; %if.end
Return
; -- End function
сделать на базе LLVM нормальный кросс-компилятор для PDP-11 весьма непросто
Негодный инструмент - плачевный результат.
Негодный инструмент - плачевный результат.Это лучшее, что есть на сегодня среди открытых компиляторных архитектур.
что стандарт C++ включает в себя синтаксически улучшенный вариант языка C
Напомнило первоапрельскую шутку. (https://forum.windowsfaq.ru/showthread.php?t=51443) :)
Daniil Chislov 86
27.08.2018, 20:57
А зачем эмулировать если можно сделать реплику ?
А зачем эмулировать если можно сделать реплику ?
например : эмулятор можно заставить работать на очень большой скорости, но по правилам оригинала (натива), т.о. компилятор macro-11 (запущенный на эмуляторе) собирает исполняемые файлы в нативной среде за пару секунд, а реплика? Будет работать 1 в 1 с оригиналом? Это можно и от хорошего эмулятора получить.
Daniil Chislov 86
27.08.2018, 23:23
Мне SKcorp говорил что он распродал большинство модулей КЦГД, упомянув что если бы остался хотя бы одна плата то продал бы мне. А есть тут у кого фотографии этой платы ?
Ну да. Эмулятор нужен для тех у кого либо нет либо был когда-то тот или иной экспонат. А реплика нужна людям у которых есть "стопяцот" нерабочих машин для поддержания их роботоспособности, либо для тех кто любит паять всякое адовое ну или для тех кто хочет спаять себе с нуля ДВК (как я).
Не судите строго.
А есть тут у кого фотографии этой платы ?
http://archive.pdp-11.org.ru/img/ms1201_02_7_by_andy7109.jpg
http://forum.maxiol.com/index.php?showtopic=4786
Daniil Chislov 86
28.08.2018, 19:25
Спасибо, а нижнюю сторону где можно найти?)
а нижнюю сторону где можно найти?)
ещё две темы по КЦГД > http://zx-pk.ru/threads/18231-ktsgd-poisk-softa-voprosy-i-otvety.html
http://zx-pk.ru/threads/23110-ktsgd-zapusk-remont-skhemy-i-td.html
Скоро будет два года как ;)
Для разминки
https://habr.com/ru/post/411989/
Скоро будет два года как
Не думаю, что в ближайшие годы стоит ждать подвижек. Когда проблемы со здоровьем стали угрожающими - захотелось закончить несколько старых проектов.
Когда проблемы со здоровьем стали угрожающими
Соболезную
Все там будем.
Лучше позже, чем раньше...
Лучше позже, чем раньше...И лучше в теме, вроде эхи FIDO TYT.BCE.HACPEM, чем здесь.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot