Разрядность команд процессора

[e2e4]

Вопрос нечеткий, хотелось бы получить хотя бы наметки ответа.

Понятно, что процессоры бывают разного назначения, скажем для целей управления, для мощных (возможно, специфических) вычислений, общего применения и т.п. Но давайте рассмотрим некоторый "среднестатистический" микропроцессор, одинаково хороший (и плохой) для всех возможных задач, ну, скажем, центральный микропроцессор для бытового ПК. Архитектура RISC/CISC, никакой экзотики.

Далее, условимся, что у него строго фиксирован размер длины поля команды (по ряду не важных в этом обсуждении причин).

Вопрос: как бы поумнее подойти к вопросу выбора этой длины команды (разрядности), добиваясь максимальной эффективности? С одной стороны, слишком короткие команды слишком просты, и требуется из большое число (т.е. кол-во обращений к памяти), чтобы выполнить некоторую задачу. С другой стороны, слишком длинные команды сильно усложняют декодер команд, и, соответственно, выполняются медленнее. Есть и ряд других соображений, которые знакомы разработчикам процессоров, я просто привел два противоположных, чтобы подчеркнуть мысль о том, что где-то должен быть некоторый оптимум размера команды с учетом конкретного применения процессора.

Также хотелось бы пообсуждать "джентельменский набора" команд процессора в привязке к предлагаемой длине команд (с учетом естественного ограничения кол-ва возможных команд), хотя, в отрыве от архитектуры, наверное это не очень актуально.

Большая просьба, не давать ответов общего характера, а также невнятных ссылок (внятные - очень желательны, однако проведя много дней тематического поиска в инете, не нашел практически ничего вразумительного). Хотелось бы услышать именно Ваши соображения по поднятому вопросу. Спасибо.

[venco]

e2e4 в сообщении #458757 писал(а):

размер длины поля команды

Не понял.

e2e4 в сообщении #458757 писал(а):

Вопрос: как бы поумнее подойти к вопросу выбора этой длины команды (разрядности),

Так "длины команды" или "разрядности"? Это разные вещи.

e2e4 в сообщении #458757 писал(а):

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

Большее число команд не означает большего количества обращений к памяти. Скорее наоборот.

e2e4 в сообщении #458757 писал(а):

С другой стороны, слишком длинные команды сильно усложняют декодер команд, и, соответственно, выполняются медленнее.

Длинные команды наоборот упрощают декодер. А медленнее они могут выполнятся потому что программа становится длиннее и требуется больше времени на чтение кода из памяти.
С другой стороны, более длинные команды дают возможность использовать больше регистров, уменьшая количество обращений к памяти за данными.

Не забывайте, что в современных компьютерах память обычно медленнее процессора, и для повышения производительности надо уменьшать количество обращений к памяти.

[e2e4]

Меня бы интересовали не современные суперпроцессоры, а методы оптимизации длины команды (разрядности) без учета всяких ухищрений. Разрядность шины данных = выбраной длине команды. За раз читается одна команда. Время ее выполнения равно времени чтения. Как-то так.

[venco]

e2e4 в сообщении #458832 писал(а):

Цитата:

Так "длины команды" или "разрядности"? Это разные вещи.

Это одинаковые вещи.

Ок. Добавим к этим словам то, к чему они относятся: "длина команды процессора", "разрядность процессора". Вы по прежнему утверждаете, что это одно и то же?

e2e4 в сообщении #458832 писал(а):

Цитата:

Большее число команд не означает большего количества обращений к памяти. Скорее наоборот.

Хух. Процессор читает из памяти по 1-й команде.

Нет. Большинство процессоров читают из памяти фиксированными блоками, например по 16 байт при минимальной длине команды 1 байт.

e2e4 в сообщении #458832 писал(а):

Не понимаю, почему Вы выискиваете неточности в моих формулировках, вместо того, чтобы дать
какие-то ответы. Или я действительно что-то написал такое, что совсем не понятно?

Неточность формулировок связана с непониманием того, как оно работает.

-- Чт июн 16, 2011 12:37:40 --

e2e4 в сообщении #458832 писал(а):

Меня бы интересовали не современные суперпроцессоры

Я имею в виду современный ширпотреб типа Пентиумов и Атлонов.

e2e4 в сообщении #458832 писал(а):

а методы оптимизации длины команды (разрядности) без учета всяких ухищрений. Разрядность шины данных = выбраной длине команды. За раз читается одна команда. Время ее выполнения равно времени чтения. Как-то так.

Ок, сферический процессор в вакууме.
В такой постановке очевидно: чем больше разрядность, тем быстрее процессор.
В идеале вся программа помещается в одну команду с минимальным количеством обращений к памяти за данными.

[e2e4]

Цитата:

Ок. Добавим к этим словам то, к чему они относятся: "длина команды процессора", "разрядность процессора". Вы по прежнему утверждаете, что это одно и то же?

Я ничего не говорил о разрядности процессора. Я говорил только о командах. Термин разрядность по отношению к команде по-вашему неприменим? Если на то пошло, то именно термин "разрядность процессора" как раз бессмысленен, а вот понятие разрядности команды, т.е. кол-во двоичных разрядов, необходимых для представления команды, вполне осмысленно.

Цитата:

Нет. Большинство процессоров читают из памяти фиксированными блоками, например по 16 байт при минимальной длине команды 1 байт.

А я предложил считать для простоты, что процессор считывает ровно одну команду за раз фиксированной длины. И степень двойки тут не причем.

Цитата:

Неточность формулировок связана с непониманием того, как оно работает.

Venco, мне нечего вам доказывать. Поверьте, ваш ликбез (в котором вы сами допускаете ошибки, как то "Длинные команды наоборот упрощают декодер.") мне не требуется.

Цитата:

Я имею в виду современный ширпотреб типа Пентиумов и Атлонов.

А я вот даже на них не замахиваюсь. И кстати, вовсе не считаю их схемотехнику и заложенные технические решения "ширпотребом". Хотелось бы разобраться с более простыми архитектурами. А вас, несомненно, с руками оторвут в Intel и AMD, когда Вы предложите менее банальные архитектуры, чем современный ширпотреб. Используйте такую возможность :).

Цитата:

Ок, сферический процессор в вакууме.
В такой постановке очевидно: чем больше разрядность, тем быстрее процессор.
В идеале вся программа помещается в одну команду с минимальным количеством обращений к памяти за данными.

Ок, мне ясно, что вам не очень интересны поднятые вопросы. Жаль, что тема с первого же ответа превратилась во флуд.

[Portnov]

Под термином «разрядность процессора» обычно понимают размер шины адреса. Т.е. количество бит, используемых для адресов памяти. С длиной команды это число зачастую никак не связано.

[e2e4]

Цитата:

Под термином «разрядность процессора» обычно понимают размер шины адреса.

Какая же по-вашему разрядность МП, скажем i386SX? i286? Core 2 Q6600?
Какой размер шины адреса - внутренний, или кол-во внешних пинов?
Какой памяти? Данных/команд/IO?

Что за дурацкий формализм и максимализм? Почему на четко сформулированный вопрос о разрядности команды (instruction width) пишутся ответы, связанные с терминологией, причем в категоричной форме? Вы взрослые люди? Конструктивно настроены на дискуссию, или так, банальной эрудицией блеснуть хочется и пофлудить? Вы действительно не поняли, что я имел ввиду, или притворяетесь?

[Chifu]

Под разрядностью процессора понимается длина регистров общего назначения и размер шины данных, но в командах важен выбор адресации операндов. С упаковкой команд проблем нет: 8 разрядный процессор - 256 команд плюс два обращения на адресацию одного операнда 16 разрядной шины адреса, 16 разрядный - 65536 команд и режимов адресации, короткие операнды плюс одно обращение к 16-разрядному смещению одного операнда. Рассмотрите систему команд i8086 это как раз тот пример когда все команды начинают умещаться в разрядность процессора и ещё свободное место остаётся для адресации операндов. Ну а 32 разрядные это полная свобода при неполном использовании адресного пространства. 64 разрядная шина данных - за одно обращение влезет один операд, 128 разрядов - влезут два операнда. Так что проблема в режимах адресации, в i8086 для этого вводится сегментация памяти. Система команд i8080 умещается на одной страничке и при работе с ним полностью запоминается в 16-тиричных кодах. В современных процессорах комады программы преобразуются во внутреннюю систему команд процессора, которая уже заточена под конвейер, предсказания ветвления, КЭШ-память, аппаратную поддержку операционной системы, параллельность и т.д., т.е. под архитектуру процессора.

[e2e4]

Цитата:

Рассмотрите систему команд i8086 это как раз тот пример когда все команды начинают умещаться в разрядность ...

Система команд IA-32 (x86) - с переменной длиной команды. Я же хотел обсудить архитектуры с постоянной длиной команды.

[Chifu]

e2e4 в сообщении #459103 писал(а):

Система команд IA-32 (x86) - с переменной длиной команды. Я же хотел обсудить архитектуры с постоянной длиной команды.

Ну тогда какие проблемы? Берёте 8 байт и будет у вас 256 команд с признаками длины и адресации операндов. Допустим признак 0 - это следующий байт в слове является командой, или текущая команда без операндов.

[Circiter]

2e2e4

Цитата:

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

Извиняйте, если глупость скажу. Но изобретая новый процессор можно попробовать сначала написать его модель, т.е. виртуальную машину, причем достаточно хорошо параметризованную VM, и уже потом произвести её экспериментальную оптимизацию на специально разработанных тестовых программульках. Другими словами, я предлагаю написать несколько VM с разными "длинами команд" и прочими специально выбранными характиристиками, замерить их производительность, построить графики, ну и, собственно, выбрать статистически наилучшее решение... :) Или так нельзя?

Кстати, а зачем вам это понадобилось? Действительно хотите самодельный процессор спаять? А это, кстати, возможно...

Цитата:

Также хотелось бы пообсуждать "джентельменский набора" команд процессора

А вы не рассматривали какие-нибудь экзотические архитектуры, предлагающие минимальное количество доступных команд, допуская в то же время компактную запись программ? Ну, скажем, что насчет процессора, напрямую реализующего комбинаторную логику (такие существуют) или лямбда-исчисление?.. :) Ну это меня уже в философию понесло, этот абзац не обязательно комментировать. :)

[Pavia]

Circiter

Цитата:

Извиняйте, если глупость скажу.

Думаю он ещё неготов чтобы воспринять результаты.

e2e4
Можем поговорить. Только чувствую вы не в теме.

Цитата:

С другой стороны, слишком длинные команды сильно усложняют декодер команд, и, соответственно, выполняются медленнее.

Как раз таки длинные команды быстрее. А поводу декодера там и там можно сделать простой декодер. Вот только чтобы по скорости угнаться декодер простых команд надо будет усложнять.

Цитата:

Но давайте рассмотрим некоторый "среднестатистический" микропроцессор, одинаково хороший (и плохой) для всех возможных задач, ну, скажем, центральный микропроцессор для бытового ПК.

Давай остановимся на этой фразе.

(Оффтоп)

Изначально микроконтроллеру выполнял одну функцию управления одним периферийным устройством.
Потом появился ЦП который выполнял множество функций. Поэтому и требования к нему широкие. Так как современный компьютер не мыслим без мультимедиа. Если раньше достаточно было обработки текста и звука, то сейчас процессор занимается обработкой фото и видео материалов и без этого не мыслим ПК. Зайдите на любой сайт и вы увидите анимированные смайлы, флешь банеры. Или целые видео ролики.

Но это ещё не придел на будущих компьютерах будет востребована симуляция или обработка видео процессов со скоростью в 1000 раз больше реального времени.

Так вот ЦП давно является специализированным.

Современный ЦП не мыслим без параллельного выполнения команд.
Так как ЦП является процессором общего назначения то от него требуется выполнять разные команды: сложение, умножение, деление, комплексное умножение, копирование блоков памяти. Так вот чтобы эти команды работали быстро нужно специальные блоки. Но тогда встаёт идея задействовать неиспользуемые блоки. Отсюда и возникают сложные команды. Которые разбиваются на простые составляющие. А за счёт параллельности операции выполняются быстрее.


Но сложные команды занимают большой объем памяти. К примеру в первых ARM команды были 32-битные. И как следствие команда читалась целиком одним блоком. Но если посчитать, то зачастую нет алгоритмов которые могли бы загрузить все блоки. Поэтому команды были еще упрощены, до 16-бит.
Это легко понять если вы начнёте делать VM.

Но это не всё зачастую ЦП требуется обрабатывать мультимедийные данные и поэтому для ускорения требуется чтобы вычислительных блоков способных выполнять одну простую операцию было много. Отсюда решение одна команда много данных.
И так далее.

[e7z0x1]

e2e4
Я рассмотрю x_{86,64}

Цитата:

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

RISC процессоры это чёртов архаизм. Все современные ядра -- CISC, все суперскалярны. То есть к конечном итоге всё равно как ты выразился происходит большое количество обращений к "памяти" а вообще-то к регистрам, коих по факту очень много(не меньше 40), хотя на уровне кода регистров общего назначения очень мало. Затраты на декодирование не имеют значения, потому что он(процессор) запоминает то что уже декодировал. Оптимизировать длину команды у тебя не получится. Потому что придется тогда брать наибольшую длину из необходимых(про sse и вариации почитай).

На самом деле есть искусственное выравнивание. Например gcc до 2.95(надо проверить как сейчас) очень любил выравнивать по 10h. Не очень понятно правда зачем. Для первопней, не иначе.

Вопрос знатокам, кстати -- нафига было делать адресацию по байтам, а обращение по словам?

>Под термином «разрядность процессора» обычно понимают размер шины адреса.
Странное утверждение. Тогда получается что pentium 3 36-разрядный процессор, а pentium 1(или pro не помню уже) 20-разрядный.

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

Кстати длина команды ещё не влияет на сложность декодера. У итаниумов длина команды огого, а декодер очень прост. А, те кто проектировал эту архитектуру на основе длинных слов отказались от фиксированной длинны. Есть повод задуматься, правда?

[e7z0x1]

Цитата:

RISC процессоры это чёртов архаизм. Все современные ядра -- CISC

CISC процессоры это чёртов архаизм. Все современные ядра -- RISC

[Chifu]

e7z0x1 в сообщении #462970 писал(а):

CISC процессоры это чёртов архаизм. Все современные ядра -- RISC

RISC это сокращённый набор команд, а не сокращённый размер команд. :) CISC это не анахронизм, а универсальный набор команд (поддержка компиляторов и операционных систем) для удобства программирования. У RISC архитектуры проще частоту наращивать, чем у СISC.