User Tag List

Страница 4 из 10 ПерваяПервая 12345678 ... ПоследняяПоследняя
Показано с 31 по 40 из 99

Тема: Про Motorola, IBM, DEC, ...

  1. #31

    Регистрация
    16.12.2014
    Адрес
    г. Ожерелье
    Сообщений
    769
    Спасибо Благодарностей отдано 
    252
    Спасибо Благодарностей получено 
    46
    Поблагодарили
    42 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  2. #31
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #32

    Регистрация
    30.11.2015
    Адрес
    г. Самара
    Сообщений
    7,508
    Спасибо Благодарностей отдано 
    344
    Спасибо Благодарностей получено 
    714
    Поблагодарили
    596 сообщений
    Mentioned
    13 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

    Цитата Сообщение от litwr Посмотреть сообщение
    Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик
    Загрузчик ему нужен. После загрузки не требуется править в памяти. Но - 64 кб.

    Цитата Сообщение от litwr Посмотреть сообщение
    Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик
    Формат .SAV из RT-11 и .TSK из RSX-11 - это аналоги .COM формата.
    Формат .REL из RT-11 - это аналог .EXE формата.
    Ну и есть такая экзотика, как .LDA формат - его аналога как то нигде не встречал

  4. #33

    Регистрация
    25.11.2015
    Адрес
    г. Москва
    Сообщений
    192
    Спасибо Благодарностей отдано 
    12
    Спасибо Благодарностей получено 
    16
    Поблагодарили
    14 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  5. #34

    Регистрация
    30.11.2015
    Адрес
    г. Самара
    Сообщений
    7,508
    Спасибо Благодарностей отдано 
    344
    Спасибо Благодарностей получено 
    714
    Поблагодарили
    596 сообщений
    Mentioned
    13 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от blackmirror Посмотреть сообщение
    Вообще-то у 8086 есть префиксы переопределения сегмента
    Вообще то речь шла о работе без троганья сегментных регистров и без префиксов

  6. #35

    Регистрация
    08.09.2005
    Адрес
    Воронеж
    Сообщений
    4,966
    Записей в дневнике
    3
    Спасибо Благодарностей отдано 
    319
    Спасибо Благодарностей получено 
    314
    Поблагодарили
    237 сообщений
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от litwr Посмотреть сообщение
    Если запретить юзеру менять значения сегментных регистров, устанавливаемых ОС при загрузке, и делать длинные переходы (их, кстати, ассемблеры не поддерживали - приходилось байтами писать),
    шта? разве что совсем какие-то древние, а в масмах-тасмах, помню, были far ptr и dword ptr

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

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

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

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

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

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

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

  7. #36

    Регистрация
    30.11.2015
    Адрес
    г. Самара
    Сообщений
    7,508
    Спасибо Благодарностей отдано 
    344
    Спасибо Благодарностей получено 
    714
    Поблагодарили
    596 сообщений
    Mentioned
    13 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  8. #37

    Регистрация
    08.09.2005
    Адрес
    Воронеж
    Сообщений
    4,966
    Записей в дневнике
    3
    Спасибо Благодарностей отдано 
    319
    Спасибо Благодарностей получено 
    314
    Поблагодарили
    237 сообщений
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    насчёт эффективных менеджеров не поспоришь
    Прихожу без разрешения, сею смерть и разрушение...

  9. #38

    Регистрация
    16.12.2014
    Адрес
    г. Ожерелье
    Сообщений
    769
    Спасибо Благодарностей отдано 
    252
    Спасибо Благодарностей получено 
    46
    Поблагодарили
    42 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от 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.
    Последний раз редактировалось litwr; 02.02.2020 в 00:03. Причина: опечатки

  10. #39

    Регистрация
    08.09.2005
    Адрес
    Воронеж
    Сообщений
    4,966
    Записей в дневнике
    3
    Спасибо Благодарностей отдано 
    319
    Спасибо Благодарностей получено 
    314
    Поблагодарили
    237 сообщений
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

    Цитата Сообщение от litwr Посмотреть сообщение
    несколько простых ограничений - не пиши в сегментые регистры и не использую длинные переходы в прикладных программах,
    совет из серии "отрубить туристу руки, чтоб легче шлось"

    Цитата Сообщение от litwr Посмотреть сообщение
    1) Да виртуализации 8086 не даёт, но защиту предоставляет хотя и не 100%.
    только уровень защиты примерно как в той самой неприличной шутке про ПВО

    Цитата Сообщение от litwr Посмотреть сообщение
    2) Да, больше у 68000 адресуемая память, но и реализована с издержками. Грузить нужно 4 байта адреса, хотя используются только 3 - в 8086 таких тормозов нет.
    зато больше есть - когда нужны 20 бит, а грузится 32
    и за данными лазить в память чаще приходится из-за недостатка регистров

    Цитата Сообщение от 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
    (что осуществимо было чисто технически)

    да и моторола именно из-за "издержек" дальше смотрела
    Прихожу без разрешения, сею смерть и разрушение...

  11. #40
    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
    Всё-таки тройная адресация по любому рулит.
    Последний раз редактировалось HardWareMan; 02.02.2020 в 08:00.

Страница 4 из 10 ПерваяПервая 12345678 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. DEC vs IBM holy war тема
    от bigral в разделе ДВК, УКНЦ
    Ответов: 218
    Последнее: 19.03.2019, 22:45
  2. CM601P клон Motorola 6800
    от Shnurkov в разделе Барахолка (архив)
    Ответов: 4
    Последнее: 15.03.2011, 11:05
  3. эмулятор zx-spectrum на motorola razr v3
    от jyly0s в разделе Эмуляторы
    Ответов: 2
    Последнее: 21.01.2007, 19:16

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •