шта-шта мог? xenix запускать штоле? так его и 68k смог прекрасно в яблочной лизе и без помощи z80Сообщение от litwr
(который и в танди не был необходим для хениха, а достался "по наследству", для совместимости)
а тем более ущербные сегменты и mmu
Прихожу без разрешения, сею смерть и разрушение...
У меня обратный опыт. Начинал с MCS51, MCS80 и x86. Потом уже М68К. А уже потом - AVR и ARM. Никаких рефлексов, чётко понимаешь плюсы и минусы той или иной архитектуры. Может всё дело в вашей вере?
Основная функция MMU это делать окружение каждой программы одиноковым с минимальными затратами физического ОЗУ. А это невозможно без сегментации. Т.е. основная проблема линейного сегмента памяти М68К такое же как и у i8080: это отсутствие возможности перемещать код в произвольное место. Z80 имеет костыль в виде 6 команд относительного перехода. А х86 сразу умел в сегменты и при компиляции адрес можно было не учитывать совсем (он полностью зависел от используемой системы, ибо именно она пилила каждый сегмент как ей хотелось). Вот и весь сказ. Сегменты выиграли из-за полностью перемещающегося кода. Это уже потом ввели функционал защиты, когда решили что программная многозадачность круче прерываний, которых, кстати, на всех и не хватит.
Разведка это intelligence, а intel это просто integrated electronics.
У Лизы был MMU, потому там Зиникс и запускался. Этот MMU ругают, но пишут, что он был быстрым. Сегменты дают функциональность MMU для небольших (до 256 КБ) программ, естественно, без защиты и виртуализации памяти. Кстати, на некоторых PDP-11 можно было иметь отдельные сегменты данных и кодов, получая до 128 КБ на процесс, но х86 давал вдвое больше и даже в самом дешёвом варианте.шта-шта мог? xenix запускать штоле? так его и 68k смог прекрасно в яблочной лизе и без помощи z80
(который и в танди не был необходим для хениха, а достался "по наследству", для совместимости)
а тем более ущербные сегменты и mmu
Общался с людьми, которые использовали Юникс с Танди. Они говорили, что без хотя и простенького MMU на базе z80 это было бы невозможно.
Тренируйте свой английский. Вот пример из словаря
information of military or political value.
"I need some intel, and I need it fast"
1960s: abbreviation of intelligence.
И сомневаюсь, что кто-то сомневается, что история с открытостью писи оказалась очень выгодной именно для Интел. Но сам тренд открытость возможно того и стоил - пошли всякие оупен-сорцы и т.п. Вот уже и железа есть немало открытого.
Последний раз редактировалось litwr; 01.02.2020 в 12:31.
Я знаю про использование сокращённой формы, но в данном контексте беседы intel имелся в виду очевидный крупный производитель полупроводниковых устройств, в частности процессоров. А их название это сокращение от указанного мной выше. И именно поэтому e немного смещена вниз, чтобы не триггерить людей с синдромом теории заговора. Хотя я не отрицаю того факта, что то, что мутировало из технологии AMT самый что ни есть откровенный бэкдор и шпион. Да, я про IntelME.
PS Интересно, а Даль вписывал в свой словарь всякие сокращения, усечения да аббревиатуры?
PPS Личный лингвист уточнил, что сокращение intel используется только в значение разведданные, это в противовес от разведка и интеллект, оба смысла которых означает полное слово.
Последний раз редактировалось HardWareMan; 01.02.2020 в 12:49.
MMU нужен в двух случаях:
- увеличение количества доступной памяти, когда из за архитектуры, промаха проектирования или привычки программистов писать раздутые программы памяти перестало хватать. Сегментные регистры 8086 - тот же MMU и попадают в эту категорию (16 битный адрес - это всего лишь 64 кб, а из за неудачной системы команд ещё и программы получались раздутыми)
- запуск нескольких процессов с возможностью защиты между процессами. При этом предполагается наличие в процессоре нескольких (как минимум двух) режимов работы разного уровня привилегированности, что бы обычные процессы не могли получить доступа к работе MMU. Очевидно, что в 8086 этого не было.
Возможность перемещать код в произвольное место - это, в первую очередь, возможность писать позиционно-независимый код. С крайне небольшими накладными расходами, на PDP-11 это возможно. Насколько это возможно на x86-x64, не могу сказать наверняка, но - известный факт - dll библиотеки в Windows линкуются с указанием базового адреса, при этом исходно Windows пытается отобразить загруженную библиотеку в адресное пространство процесса с этого же базового адреса и если это невозможно (в адресное пространство процесса уже отображена dll библиотека с этого же базового адреса) - windows по информации из dll библиотеки патчит код в памяти для работы с другого базового адреса. Не могу сказать, почему пошли таким путём в Windows, но могу предположить, что накладные расходы могли оказаться слишком большими или это вообще не возможно (на это намекает ещё тот факт, что, насколько мне не изменяет память, в x86-x64 нет относительных переходов на произвольное расстояние, в то время как в PDP-11 таких возможностей аж две - короткий переход - основной плюс - команда в одно слово и длинный переход). Так же не могу сказать, как обстоят дела с аналогом dll библиотек в unix-подобным системах.
Да, сегментные регистры, а точнее возможность префиксом для команды указать использование другого сегментного регистра - это интересная и в ряде сценариев удобная возможность, но - их роль в сценарии по умолчанию (то есть когда префикс не используется) достаточно узко специализированная и их не такое большое количество (в исходном 8086 всего 4, причём только 3 используется по умолчанию), при этом, если требуется использовать другой блок памяти - нужно всё равно явно грузить и уж ни о какой защите на изменение содержимого регистра речи не идёт.
Если посмотреть на модель MMU в PDP-11 - во первых их больше (7+1), во вторых они универсальны (и только в определённых моделях была реализована специализация, но при этом и количество регистров увеличилось до 15+1), в третьих - их легко защитить от неконтролируемой смены (и есть контролируемый ОС процесс изменения), так же, как и в 8086 есть необходимость явной загрузки. Ну и минусом можно записать, что для команды нельзя указать префиксом - какой регистр (регистры) будет(будут) использоваться.
- - - Добавлено - - -
Вдогонку. С M68k работать не приходилось, сказать ничего не могу, на ассемблере x86-x64 много писать не приходилось, но после удобной системы команд PDP-11 - считаю крайне не удобным. А также - тот же самый (по функционалу) код на PDP-11 получается гораздо короче - спасибо и системе команд и режимам адресации. В своё время для меня было до некоторой степени шоком, что такая ограниченная по возможностям и однозадачная система MS-DOS требовала для себя столько памяти, при том что первые версии были так же написаны на ассемблере. Это то же о чём то, но говорит.
Условные переходы в x86 изначально были со смещением в байт, для перехода в пределах сегмента нужно было делать обход команды безусловного перехода по инверсному условию. Хотя при смещении размером в слово были и абсолютные и относительные формы переходов и вызовов подпрограмм. Для дальних переходов с перезагрузкой сегментного регистра адрес уже всегда абсолютный.
Начиная с 386 в систему команд добавили условные относительные переходы со смещением размером в слово, то есть сам код сделать позиционно-независимым легко. Проблема только в лежащих внутри него данных, поскольку единственный способ узнать текущий IP это call на команду pop.
Для x86-64 добавили режимы адресации позволяющие читать данные относительно IP, то есть там проблем с позиционно независимым кодом нет вообще, за исключением того, что смещение всего 4 байта и далее +-2Гб данные не достанешь. Кстати все арифметические команды с константами тоже принимают 4 байта, знаково или беззнаково их расширяя. Единственное что можно сделать с 8 байтной закодированной в команду константой, это загрузить её в регистр.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
а вот здесь поподробнее, какую такую "функциональность mmu" без виртуализации и защиты (которые и есть основная функция mmu)?
и что за зверь такой "небольшая (до 256 кб) программа x86"? для меня, если сказано "программа" - значит, программный код
не скажу сейчас про хених, но в досе размер кода более 64кб требовал exe формата, чтобы патчить код при загрузке
(что, естественно, проделать можно на любом процессоре с любой осью)
Прихожу без разрешения, сею смерть и разрушение...
Это уже значительно более современные процы, к тому же 32 битные
Попробуйте сделать такое на 8086, который, как и PDP-11 - 16-ти битный.
Если продолжать развивать идеи PDP-11 на 32-битный вариант (VAX, с моей точки зрения - значительный отход от этих идей) - все узкие места из за 16-ти битности точно так можно исправить. И вот этот (гипотетический) проц можно будет сравнивать с 386 и далее процами. И он так же будет лучше по системе команд, ибо это заложено было изначально. А 386 и далее точно так же будет кривым. Такова цена совместимости.
Ещё плата за слишком запутанную систему команд - необходимость делать вертикальный микрокод, то есть по сути внутри проца интерпретатор.
Хотя с моей точки зрения - микрокод (как и синхронные схемы) в принципе ущербный подход, но это отдельная тема.
- - - Добавлено - - -
4 сегментных регистра, если без их перезагрузки, и дают как раз 256 кб. Но строго говоря - 192 + 64. Примерный аналог - процы PDP-11 с поддержкой пространства данных - до 128 кб
- - - Добавлено - - -
Сам формат com был ограничен 64 кб в принципе. .exe как раз обходит это ограничение. А нужно ли патчить или нет - это вопрос второй.
Виртуализация и защита - одна из двух функциональностей mmu, но не обязательная. Хотя в PDP-11, скажем, присутствовали обе.
они не дают "программу 256 кб" и без их перезагрузки на x86 толком ничего полезного не поделаешь (не намного больше, чем может com)
- - - Добавлено - - -
чсх, вновь туманные намёки на таинственную "остальную функциональность" вместо внятного и членораздельного описания))
Прихожу без разрешения, сею смерть и разрушение...
Сегмент кода, сегмент данных, сегмент стека, доп сегмент. Содержимое сегментного регистра - номер 16-ти байтного блока, то есть при вычислении реального адреса можно сказать, что его содержимое сдвигается на 4 бита влево и складывается с адресом из ip или команды.
Пусть CS=0, DS=1000, SS=2000, ES=3000. Тогда реальные адреса команд попадут в диапазон 0000-FFFF, данных - 10000-1FFFF, стека 20000-2FFFF, доп сегмента - 30000-3FFFF, итого общий объём - 00000-3FFFF или 256 кб. Но. Это не увеличит максимальный объём кода, данных или стека - всё равно останется по 64 кб, а доп регистр используется только на строковых командах, поэтому я и написал - 192+64. В целом - надо достаточно извратиться, что бы по полной использовать эти 256 кб без перезагрузки регистров, но технически это возможно.
Я всё написал в первом сообщении.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
