Если регистры так невероятно быстры, почему у нас их не больше?

есть много причин, по которым у вас не просто огромное количество регистров:

• они сильно соединены к большинств этапам трубопровода. Для начала вам нужно отслеживать их продолжительность жизни и пересылать результаты обратно на предыдущие этапы. Сложность становится трудноразрешимой очень быстро, и количество проводов (буквально) растет с той же скоростью. Это дорого по площади, что в конечном счете означает, что это дорого по мощности, цене и производительности после определенного момента.
• Это занимает пространство кодирования инструкций. 16 регистров занимают 4 бита для источника и назначения, и еще 4, Если у вас есть 3-операнд инструкции (e.G ARM). Это ужасно много пространства кодирования набора инструкций, занятого только для указания регистра. Это в конечном итоге влияет на декодирование, размер кода и снова сложность.
• есть лучшие способы достичь того же результата...

в наши дни у нас действительно много регистров - они просто не запрограммированы явно. Мы есть "регистрация переименования". Хотя вы получаете доступ только к небольшому набору (8-32 регистрам), они фактически поддерживаются гораздо большим набором (e.g 64-256). Затем процессор отслеживает видимость каждого регистра и выделяет их переименованному набору. Например, вы можете загружать, изменять, а затем хранить в регистре много раз подряд, и каждая из этих операций фактически выполняется независимо в зависимости от пропусков кэша и т. д. В руке:

ldr r0, [r4]
add r0, r0, #1
str r0, [r4]
ldr r0, [r5]
add r0, r0, #1
str r0, [r5]

ядра Cortex A9 регистрируют переименование, поэтому первая загрузка к "r0" фактически переходит переименованный виртуальный регистр - назовем его "v0". Нагрузка, инкремент и магазин происходят на "v0". Между тем, мы также снова выполняем загрузку/изменение/store в r0, но это будет переименовано в "v1", потому что это полностью независимая последовательность с использованием r0. Допустим, загрузка из указателя в "r4" остановилась из-за промаха кэша. Все в порядке - нам не нужно ждать, пока "r0" будет готов. Поскольку он переименован, мы можем запустить следующую последовательность с "v1" (также сопоставленную с r0) - и, возможно это хит кэша, и у нас только что была огромная победа в производительности.

ldr v0, [v2]
add v0, v0, #1
str v0, [v2]
ldr v1, [v3]
add v1, v1, #1
str v1, [v3]

Я думаю, что x86 - это гигантское количество переименованных регистров в эти дни (ballpark 256). Это означало бы иметь 8 бит раз 2 для каждой инструкции, чтобы просто сказать, что такое источник и назначение. Это значительно увеличило бы количество проводов, необходимых для сердечника, и его размер. Таким образом, есть сладкое пятно вокруг 16-32 регистров, на которые большинство дизайнеров согласились, а для неупорядоченных проектов CPU зарегистрируйте переименование-это способ смягчить его.

редактировать: важность внеочередного исполнения и переименования регистра на этом. Как только у вас есть OOO, количество регистров не имеет большого значения, потому что они просто "временные теги" и переименовываются в гораздо больший набор виртуальных регистров. Вы не хотите, чтобы число было слишком маленьким, потому что становится трудно писать небольшие кодовые последовательности. Это проблема для x86-32, потому что ограниченные 8 регистров означают много временные файлы в конечном итоге проходят через стек, и ядро нуждается в дополнительной логике для пересылки чтения/записи в память. Если у вас нет OOO, вы обычно говорите о небольшом ядре, и в этом случае большой набор регистров-это плохая стоимость/производительность.

таким образом, есть естественное сладкое пятно для размера банка регистров, которое составляет около 32 архитектурных регистров для большинства классов CPU. x86-32 имеет 8 регистров, и он определенно слишком мал. ARM пошел с 16 регистрами, и это хорошо компромисс. 32 регистра немного слишком много, если что-то-вам не нужны последние 10 или около того.

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