caxapa.ru :: На мой взгляд в системе команд PDP-11 было избыточное количество адресаций. Поэтому никто её не повторяет в МК. Неэффективно.

=AlexD= (02.06.2022 15:32, просмотров: 221) ответил LightElf на Можно было (наверно), но задачей была совместимость с PDP-11.

На мой взгляд в системе команд PDP-11 было избыточное количество адресаций. Поэтому никто её не повторяет в МК. Неэффективно.

Три кита на которых зиждется реклама: враньё, преувеличение, замалчивание. Новости СМИ - это политическая реклама.

Ответить

- PDP-11 - продукт своего времени. Операции "память-память" вполне себе рулят, если память работает со скоростью проца. - LightElf(02.06.2022 16:22)
  - Ну давай сравним, 32х разрядный ARM1 работал на частоте 8МГц, имел 3х ступенчатый конвейер и его производительность была ограничена памятью до примерно 3MIPS, 1801 работал на частоте 5МГц и его производительность в 0.5MIPS не была ничем ограничена. Разница в 6 лишних команд не достаточно, чтобы скомпенсировать отсутствие команд память-память? А если крохотный кеш добавить и даже просто очередь команд? - =AlexD=(02.06.2022 16:48)
    - В данном разрезе бессмысленно рассматривать 1801 отдельно от PDP-11 и Q-Bus как таковых. Ибо стояла задача сделать микропроцессор, сохранив бинарную совместимость с более ранними мини-ЭВМ и электрическую совместимость с шиной Q-Bus (которая сама по себе ограничивает производительность на уровне, емнип, 1Мипс). - LightElf(02.06.2022 17:06)
- оно архисложно конвейеризуется из-за огромного числа зависимостей, а короткий конвейер = низкая частота. а на низкой частоте такие решения очень эффективны. неспроста экономичные в момент своего появления MSP430 разменяли всего один бит типа адресации на бит количества регистров, а в целом повторяют идею PDP-11. - Mahagam(02.06.2022 15:47)
  - Это всё несущественно, при желании можно и конвейеризировать, и ускорить регистровые команды и даже ОоОЕ прикрутить. Там проблема в том что коды операций зарезервированы за редко используемыми комбинациями адресаций, которые проще было бы отдельными командами реализовать. - =AlexD=(02.06.2022 15:59)
    - всё это "несущественное" мы частично видим в развитии x86 - сложнейший декодер команд, и всякие там прикрученные OoOE сами по себе чуть ли не толще целого ядра арма. а биты, что уходили на адресацию адресаций, теперь уходят на адресацию регистров, которых нужно дохрена. - Mahagam(02.06.2022 16:10)
      - И чего плохого? Сравни любые процессорные ядра с РОН внутри АЛУ и в ОЗУ (авр и 51й) - арифметика на первых просто на голову эффективнее. - POV(02.06.2022 16:19)
      - В том то и дело, что память тормознутее процессора, поэтому адресация из памяти в память никак программу не ускоряет, а расширение регистрового банка - ускоряет. Пака данные подтянутся, можно не только новые адреса вычислить, но и ещё остальную регистровую арифметику успеть. - =AlexD=(02.06.2022 16:16)
        
        зависит от алгоритмов и задач. иногда слазить в кэш намного быстрее, чем прочитать лишних три команды. собственно, любые алгоритмы которые что-то там жирное считают регистрами не обойдутся - в память так или иначе лазить придётся, потому и без кэша сейчас ничего нет (ну или TCM на случай контроллеров) - Mahagam(02.06.2022 16:46)
        
        Если есть кеш данных, то есть и кеш команд, и это разные кеши с разными шинами, и эти три команды считай бесплатны. Слазить в кеш это пара тактов, а регистровые команды все утрамбовываются в конвейер без зазоров. - =AlexD=(02.06.2022 16:53)
        
        все равно нельзя ж бесконечно играцца в песочнице и считать в регистрах - один хрен эти регистры надо заполнять свежими данными, и сохранять в память результаты. а это все равно обращения к памяти/кэшу. - Mahagam(02.06.2022 17:01)
        
        Верно, проблемы начинаются когда места в песочнице не хватает, и нужно пихать в стек промежуточные результаты. Чем шире регистровый файл, тем реже такая ситуация возникает. Единственное препятствие к расширению регистрового файла это ширина команды. - =AlexD=(02.06.2022 17:12)
        
        тьма алгоритмов которые работают с килобайтами/мегабайтами информации. всякие там перемножения конских матриц, обработка картинок, фильтры аудио над буферами, там никакое расширение регистрового файла не спасёт. как только в регистрах умещается вся инфа для удобной адресации входных и выходных данных, так сразу дальнейшее расширение регистров не нужно. и один фиг - всё сводится к большому кэшу. да и вообще - к трём уровням кэшей. - Mahagam(02.06.2022 17:28)
        
        Если одни не ускоряются, это не значит что нужно забить на другие, которые ускоряются. Тем более потоковые алгоритмы ускоряют массово-параллельными вычислителями, там важнее не количество регистров, а их эффективная "ширина". Одно другому в общем не мешает. - =AlexD=(02.06.2022 17:43)
        
        потоковые алгоритмы без конских кэшей и без быстрой памяти не обходятся. иначе им некуда пихать результаты своих потоков. - Mahagam(02.06.2022 17:52)
        
        Для потоковых алгоритмов размер кеша не играет рояли, они любой кеш забивают, достаточно кешировать по крайней мере две страницы драм. =AlexD=(380 знак., 03.06.2022 07:58)

Микроконтроллеры