Mahagam (02.06.2022 15:47, просмотров: 178) ответил =AlexD= на На мой взгляд в системе команд PDP-11 было избыточное количество
адресаций. Поэтому никто её не повторяет в МК. Неэффективно.-
- Это всё несущественно, при желании можно и конвейеризировать, и
ускорить регистровые команды и даже ОоОЕ прикрутить. Там проблема в
том что коды операций зарезервированы за редко используемыми
комбинациями адресаций, которые проще было бы отдельными командами
реализовать. - =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)
- потоковые алгоритмы без конских кэшей и без быстрой памяти не
обходятся. иначе им некуда пихать результаты своих потоков. - Mahagam(02.06.2022 17:52)
- Если одни не ускоряются, это не значит что нужно забить на другие,
которые ускоряются. Тем более потоковые алгоритмы ускоряют
массово-параллельными вычислителями, там важнее не количество
регистров, а их эффективная "ширина". Одно другому в общем не
мешает. - =AlexD=(02.06.2022 17:43)
- тьма алгоритмов которые работают с килобайтами/мегабайтами
информации. всякие там перемножения конских матриц, обработка
картинок, фильтры аудио над буферами, там никакое расширение
регистрового файла не спасёт. как только в регистрах умещается вся
инфа для удобной адресации входных и выходных данных, так сразу
дальнейшее расширение регистров не нужно. и один фиг - всё сводится
к большому кэшу. да и вообще - к трём уровням кэшей. - Mahagam(02.06.2022 17:28)
- Верно, проблемы начинаются когда места в песочнице не хватает, и
нужно пихать в стек промежуточные результаты. Чем шире регистровый
файл, тем реже такая ситуация возникает. Единственное препятствие к
расширению регистрового файла это ширина команды. - =AlexD=(02.06.2022 17:12)
- все равно нельзя ж бесконечно играцца в песочнице и считать в
регистрах - один хрен эти регистры надо заполнять свежими данными,
и сохранять в память результаты. а это все равно обращения к
памяти/кэшу. - Mahagam(02.06.2022 17:01)
- Если есть кеш данных, то есть и кеш команд, и это разные кеши с
разными шинами, и эти три команды считай бесплатны. Слазить в кеш
это пара тактов, а регистровые команды все утрамбовываются в
конвейер без зазоров. - =AlexD=(02.06.2022 16:53)
- зависит от алгоритмов и задач. иногда слазить в кэш намного
быстрее, чем прочитать лишних три команды. собственно, любые
алгоритмы которые что-то там жирное считают регистрами не обойдутся
- в память так или иначе лазить придётся, потому и без кэша сейчас
ничего нет (ну или TCM на случай контроллеров) - Mahagam(02.06.2022 16:46)
- всё это "несущественное" мы частично видим в развитии x86 -
сложнейший декодер команд, и всякие там прикрученные OoOE сами по
себе чуть ли не толще целого ядра арма. а биты, что уходили на
адресацию адресаций, теперь уходят на адресацию регистров, которых
нужно дохрена. - Mahagam(02.06.2022 16:10)
- Это всё несущественно, при желании можно и конвейеризировать, и
ускорить регистровые команды и даже ОоОЕ прикрутить. Там проблема в
том что коды операций зарезервированы за редко используемыми
комбинациями адресаций, которые проще было бы отдельными командами
реализовать. - =AlexD=(02.06.2022 15:59)