Про Motorola, IBM, DEC, ...

Вид для печати

Показывать 40 сообщений этой темы на одной странице

01.02.2020, 19:18
litwr

Может мне получится объяснить. Если запретить юзеру менять значения сегментных регистров, устанавливаемых ОС при загрузке, и делать длинные переходы (их, кстати, ассемблеры не поддерживали - приходилось байтами писать), то получаем отличный ММЮ, имея до 256 КБ на процесс с никакими затратами на релокацию - не хватает только виртуалки для полного многозадачного счастья из 100 задач разом. В лучших PDP11 дают только 128 КБ. Простейшее ММЮ - это два регистра базы (для данных и кода) и два соответствующих регистра-лимита - так и было в Танди 16, а мой знакомый такое недавно на ПЛИС запилил для поддержки Миникс на ЦП без своего ММЮ.
Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик, - это благодаря полу-ММЮ 8086. Для 68к таких форматов не было и быть не могло.
01.02.2020, 19:25
Hunta

Цитата:

Сообщение от litwr

до 256 КБ на процесс

При условии, что мы уместимся кодом в 64 кб, данными - в 64 кб, данными и адресами возврата на стеке - в 64 кб, строками - в 64 кб. Если чего то из этого у нас меньше, чем на 64 кб - лишнее под другой тип инфы использовать не получится. А учитывая, что строки - это весьма специфический тип данных, я и написал - 192+64.

Цитата:

Сообщение от litwr

Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик

Загрузчик ему нужен. После загрузки не требуется править в памяти. Но - 64 кб.

Цитата:

Сообщение от litwr

Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик

Формат .SAV из RT-11 и .TSK из RSX-11 - это аналоги .COM формата.
Формат .REL из RT-11 - это аналог .EXE формата.
Ну и есть такая экзотика, как .LDA формат - его аналога как то нигде не встречал
01.02.2020, 19:37
blackmirror

Вообще-то у 8086 есть префиксы переопределения сегмента, то есть данные ему доступны из всех 256К, причём из сегмента стека он их может брать и без переопределения сегмента, если при адресации используется регистр bp. А вот у 386 появилось еще два сегментных регистра, так что в реальном режиме через префиксы ему будет доступно 384К без перезагрузки сегментных регистров.
01.02.2020, 20:02
Hunta

Цитата:

Сообщение от blackmirror

Вообще-то у 8086 есть префиксы переопределения сегмента

Вообще то речь шла о работе без троганья сегментных регистров и без префиксов
01.02.2020, 20:05
Lethargeek

Цитата:

Сообщение от litwr

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

шта? разве что совсем какие-то древние, а в масмах-тасмах, помню, были far ptr и dword ptr

Цитата:

Сообщение от litwr

то получаем отличный ММЮ,

нет, в первую очередь получаем еще более хреновый процессор, чем 8086 без этих ограничений
с одним-единственным и весьма сомнительным плюсом - чуть более быстрым запуском программ (меньше патчинга)

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

Цитата:

Сообщение от blackmirror

Вообще-то у 8086 есть префиксы переопределения сегмента, то есть данные ему доступны из всех 256К,

но не код

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

итого в сухом остатке сегментация 8086:

1) не даёт никакой виртуализации и защиты
2) "расширяет" память процесса хуже и меньше, чем процесс m68k имеет без таких "расширений"
3) полноценная релокация без танцев с бубном только для com (а с бубном патчить можно и без сегментов)

то есть сегменты 8086 никаким конкурентным преимуществом перед m68k являться не могут
а являются уродливым костылём, в лучшем случае позволяющим лишь немного сократить отставание
01.02.2020, 20:27
Hunta

Цитата:

Сообщение от Lethargeek

а являются уродливым костылём, в лучшем случае позволяющим лишь немного сократить отставание

А на выходе мы имеем, что из за господ менеджеров DEC таки просрала рынок с потенциально лучшей 16-ти битной архитектурой. Ибо в серии Pro они слепили из конфетки ***** (причём в определённых аспектах даже хуже PC), а серия VAX изначально была нацелена не на рынок персоналок и только потом они что то начали лепить персонально-подобное. И - запрет создания аналогов, плюс у DEC, в отличии от той же Apple, были гораздо худшие маркетологи, так что неконфетку никто не смог (да и не смог бы по любому) продать за бешенные бабки. Ну а дальше всё понятно.
01.02.2020, 21:50
Lethargeek

насчёт эффективных менеджеров не поспоришь
01.02.2020, 23:57
litwr

Цитата:

Сообщение от Hunta

Вдогонку. С M68k работать не приходилось, сказать ничего не могу, на ассемблере x86-x64 много писать не приходилось, но после удобной системы команд PDP-11 - считаю крайне не удобным. А также - тот же самый (по функционалу) код на PDP-11 получается гораздо короче - спасибо и системе команд и режимам адресации. В своё время для меня было до некоторой степени шоком, что такая ограниченная по возможностям и однозадачная система MS-DOS требовала для себя столько памяти, при том что первые версии были так же написаны на ассемблере. Это то же о чём то, но говорит.

Очень странное замечание. У х86 очень хорошая плотность кодов, тут они всегда обгоняли Армы и даже которые "с пальчиком". У PDP-11 код по плотности хуже, чем на х86, где команды могут иметь длину 1 или 3 байта, а на они PDP-11 всегда кратны 2. ДОС и называли "быстрой и грязной" - скопипастели код СР/М, который был на 8080-ассемблере. Потом, кажется с версии 3, перешли на си. И чем же ДОС ограниченная по сравнению с RT-11? Имена файлов длиннее, есть каталоги и юникс-переодресация потоков, возможность делать TSR-програмы (это неофициальная, но многозадачность), памяти намного больше, ... И сама ДОС не так уж и много требовала памяти - влезала в himem. Некоторые менеджеры памяти давали до 800 кб юзеру. Конечно, программистам 80-х уже не надо было так бороться за каждый байт, как тем, кто писал RT-11 в 70-е.

Цитата:

Сообщение от Hunta

При условии, что мы уместимся кодом в 64 кб, данными - в 64 кб, данными и адресами возврата на стеке - в 64 кб, строками - в 64 кб. Если чего то из этого у нас меньше, чем на 64 кб - лишнее под другой тип инфы использовать не получится. А учитывая, что строки - это весьма специфический тип данных, я и написал - 192+64.

Загрузчик ему нужен. После загрузки не требуется править в памяти. Но - 64 кб.

Формат .SAV из RT-11 и .TSK из RSX-11 - это аналоги .COM формата.
Формат .REL из RT-11 - это аналог .EXE формата.
Ну и есть такая экзотика, как .LDA формат - его аналога как то нигде не встречал

Да, код не более 64 кб, а данных до 192 кб. И почему это нельзя сегментные регистры использовать? Очень даже можно - это ММЮ никак не порушит. Нет у СОМ никакого загрузчика - это чистый код - и такого ни для какой другой архитектуры не знаю - это пример, когда процентов 20% всех возможностей из сегментов поиспользовали. А SAV и TSK имеют очень даже заметные загрузчики. В Atari ST, система которой сделана копированием ДОС и Досовского Гем, есть аналог СОМ-формата, но с загрузчиком. Не знаю что за LDA - дайте ссылку, но уверен, что и близко не ДОС СОМ.

Цитата:

Сообщение от Lethargeek

шта? разве что совсем какие-то древние, а в масмах-тасмах, помню, были far ptr и dword ptr

нет, в первую очередь получаем еще более хреновый процессор, чем 8086 без этих ограничений
с одним-единственным и весьма сомнительным плюсом - чуть более быстрым запуском программ (меньше патчинга)

но не код

итого в сухом остатке сегментация 8086:

1) не даёт никакой виртуализации и защиты
2) "расширяет" память процесса хуже и меньше, чем процесс m68k имеет без таких "расширений"
3) полноценная релокация без танцев с бубном только для com (а с бубном патчить можно и без сегментов)

то есть сегменты 8086 никаким конкурентным преимуществом перед m68k являться не могут
а являются уродливым костылём, в лучшем случае позволяющим лишь немного сократить отставание

ДОС одназадачная система, где приоритетом выбрали использование всей памяти одним процессом, а не многими процессами её части как в PDP-11, где вас почему-то сегменты по 64 КБ не смущают никак, а некоторых даже умиляют. На 8086 вполне можно было всё хозяйство PDP-11 переносить, сегменты просто всё управление памятью разруливали. Писал уже, что ММЮ нужны только две базы и два лимита, у 8086 есть четыре (!) базы и четыре фиксированных лимита по 64 кб. Ставь Юникс запросто, только выполняй несколько простых ограничений - не пиши в сегментые регистры и не использую длинные переходы в прикладных программах, т.е. для полной защиты памяти не хватает только превилигированного режима для названных операций.

1) Да виртуализации 8086 не даёт, но защиту предоставляет хотя и не 100%.

2) Да, больше у 68000 адресуемая память, но и реализована с издержками. Грузить нужно 4 байта адреса, хотя используются только 3 - в 8086 таких тормозов нет. И, повторю, в начале 80-х один мб и более ставили только на очень дорогие системы, с которыми 68000 конкурировать не мог из-за отсутствия ММЮ и сопра. Реально преимущества 68000 перед 8086 стали доступны людям только с 1983, когда уже был 80286, который значительно шустрее 68000, имел встроенное ММЮ и поддержку сопра. Если бы на Амиги и Атари СТ поставили 80286, получились бы гораздо более крутые системы - там ДОСа не было и всё сразу можно было делать в защищенном режиме или через LOADALL - возможно и сейчас бы ещё их выпускали.

3) Это не так уж и мало - выгрузил из дебаггера код в СОМ-файл и тут же запустил его как программу - очень даже приятная особенность, которую утратили с переходом на более тяжёлые оси.

Что-то путаете, 8086/8088 появились раньше 68000 более чем на год и это было их существенным преимуществом. Интел сразу стала их производить массово, а мотороловцы наладили массовый выпуск только после 1980. Поэтому в фразе "немного сократить отставание" что-то съехало. Если вам сегменты кажутся "уродливым костылём", то возможно у вас такие вкусы. Но если хотите по существу, то предложите другой способ лучшим образом организовать адресацию памяти, чем это было сделано в х86. Только не забывайте, что вы должны сделать это для реалий 1978 с перспективой лет на 5.
02.02.2020, 00:57
Lethargeek

Цитата:

Сообщение от litwr

У х86 очень хорошая плотность кодов, тут они всегда обгоняли Армы

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

Цитата:

Сообщение от litwr

ДОС одназадачная система, где приоритетом выбрали использование всей памяти одним процессом, а не многими процессами её части как в PDP-11, где вас почему-то сегменты по 64 КБ не смущают никак,

про пдп я вообще пока что не говорил

Цитата:

Сообщение от litwr

несколько простых ограничений - не пиши в сегментые регистры и не использую длинные переходы в прикладных программах,

совет из серии "отрубить туристу руки, чтоб легче шлось"

Цитата:

Сообщение от litwr

1) Да виртуализации 8086 не даёт, но защиту предоставляет хотя и не 100%.

только уровень защиты примерно как в той самой неприличной шутке про ПВО :D

Цитата:

Сообщение от litwr

2) Да, больше у 68000 адресуемая память, но и реализована с издержками. Грузить нужно 4 байта адреса, хотя используются только 3 - в 8086 таких тормозов нет.

зато больше есть - когда нужны 20 бит, а грузится 32 :p
и за данными лазить в память чаще приходится из-за недостатка регистров

Цитата:

Сообщение от litwr

И, повторю, в начале 80-х один мб и более ставили только на очень дорогие системы, с которыми 68000 конкурировать не мог из-за отсутствия ММЮ и сопра.

вообще-то в начале 80-х именно м68к и ставили в дорогие профессиональные рабочие станции, иногда и мультипроцессорные

Цитата:

Сообщение от litwr

Реально преимущества 68000 перед 8086 стали доступны людям только с 1983, когда уже был 80286, который значительно шустрее 68000,

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

Цитата:

Сообщение от litwr

имел встроенное ММЮ и поддержку сопра. Если бы на Амиги и Атари СТ поставили 80286,

...то их в 1986 никто бы не купил из-за конских ценников (так же как и системы на 68020)
кстати, mmu производители домашних компов предпочитали свой встраивать в чипсет с учётом видеоподсистемы

Цитата:

Сообщение от litwr

3) Это не так уж и мало - выгрузил из дебаггера код в СОМ-файл и тут же запустил его как программу - очень даже приятная особенность, которую утратили с переходом на более тяжёлые оси.

не понимаю смысла этого действа - екзешный код не заработает в ком-формате (разве что мелкие чисто вычислительные фрагменты), а комовский и так в дебагере крутится

Цитата:

Сообщение от litwr

Что-то путаете, 8086/8088 появились раньше 68000 более чем на год и это было их существенным преимуществом. Интел сразу стала их производить массово, а мотороловцы наладили массовый выпуск только после 1980. Поэтому в фразе "немного сократить отставание" что-то съехало.

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

Цитата:

Сообщение от litwr

Если вам сегменты кажутся "уродливым костылём", то возможно у вас такие вкусы. Но если хотите по существу, то предложите другой способ лучшим образом организовать адресацию памяти, чем это было сделано в х86? Только не забывайте, что вы должны сделать это для реалий 1978 с перспективой лет на 5.

например, arm+thumb с перспективой лет так на 35 :p
(что осуществимо было чисто технически)

да и моторола именно из-за "издержек" дальше смотрела
02.02.2020, 07:51
HardWareMan

Я тут имел реальную ситуацию, которая может примерно оценить некоторые параметры при сравнении x86 и ARM. Я делал частную изменённую реализацию математики RIPEMD сначала на х86, а потом на ARM. Обе для получения максимальной скорости на ассмеблере. Вот, например, один из раундов:

Код:

ecx := Rol9( (ecx + PDWord(@HashBuf[0])^) + (((eax xor ebx) and edx) xor ebx) ); 1: add ecx,dword ptr NEWHASH[0] 2: mov esi,eax 3: xor esi,ebx 4: and esi,edx 5: xor esi,ebx 6: add ecx,esi 7: rol ecx,$00000009 1: EOR R8, R0, R1 2: AND R8, R8, R3 3: EOR R8, R8, R1 4: ADD R8, R8, R4 5: ADD R2, R2, R8 6: ROR R2, R2, #23

Видно, что ARM имеет достаточно регистров, чтобы поместить в них все необходимые переменные (это два набора по 128 бит, + 64 бита исходные данные + пара регистров на времянку), а у x86 кое-что (исходные данные) приходится оставлять в памяти. Так же тройная адресация ARM экономит как минимум 1 инструкцию (далее есть раунды где экономится 2 инструкции). В итоге, пиковая производительность счёта в коротком цикле составляет примерно 10MH/s на 3GHz в одном потоке для х86 (пробовал и Pentium D и на Core i7 - одинаково) и примерно 330kH/s в одном потоке на ARM CortexM4 168MHz (STM32F4xx). Получается, что у первого 300 хэшей на 1 МГц, а у второго всего ~1,964. Длину получаемого кода не сравнивал, у ARM включен палец. Было бы интересно проверить на более мощных ARMv7+, которые умеют в гигагерцы, чтобы быть в одинаковой позиции хотя-бы по тактовой частоте.

PS Чтобы быть честным, то реализация этого алгоритма на паскале или С (первая строчка в тэге код) даёт пиковую производительность в 150-200кH/s, что даже ниже чем у контроллера. Именно перепись на ассемблер дало такой громадный скачок. Правда, какие-то ключи оптимизации компиляторов я не пробовал, но не думаю, что там будет быстрее, чем 800к. Есть мнение, что вся процедурка (а это порядка 300 инструкций) тупо поместилась в кэше процессора отсюда и такой аномальный буст. Вот так вот.

PPS Вот еще один раунд с другой математикой:

Код:

eax := Rol7( (eax+$5A827999) + (((ecx or edx) and ebx) or (ecx and edx)) ); 1: add eax,$5A827999 2: mov esi,ecx 3: mov edi,ecx 4: or esi,edx 5: and esi,ebx 6: and edi,edx 7: or edi,esi 8: add eax,edi 9: rol eax,$00000007 1: ORR R8, R2, R3 2: AND R8, R8, R1 3: AND R9, R2, R3 4: ORR R8, R8, R9 5: ADD R8, R8, R6 6: ADD R0, R0, R8 7: ROR R0, R0, #25

Всё-таки тройная адресация по любому рулит.

Показывать 40 сообщений этой темы на одной странице