Что делать когда нехватает регистров?

Pavia

я думаю тут спорить не уместно, всё зависит от ситуации.
может код быть и полным AGI и предвыборка курит в сторонке

 

Я вот здесь не совсем понимаю. Перед тем как расчитать что-то нужно загрузить это "что-что" . Невозможно сложить 2 числа, если эти два числа не загружены в озу->кэш->регистры. На каждый этап -> требуется время, каким бы оно там минимальным не было,но требуется.

 

Я может быть не совсем правильно сказал. Может быть не такты, но какое то лишнее время на загрузку из кэша(даже L1) в регистры всё равно уходит. Обмен данными между регистрами происходит на скорости тактовой частоты процессора, а обмен данными между кэшем и регистрами происходит на скорости частоты кэша!

 

fluck
Время на загрузку тратится, но на скорость программы оно не влияет. Скорость кэша первого уровня равна скорости процессора.

Тут решил побаловаться со флешем вот что получилось. Изображение схематическое.

 

Время на загрузку данных из кэша конечно нужно. Стандартная величина для L1 = 3 тактам = 1 на вычисление адреса и формирование запроса в кэш + 1 на трансляцию адреса и хит-тест в кэше + 1 такт на передачу данных из кэша.
Однако, во-первых, все это дело конвееризовано, поэтому запросы на загрузку в пеньках могут выполняться в каждом такте, а в атлонах и вовсе по 2 за один такт. Поэтому если не считать начальную задержку, то цепочка операций загрузки будет выполняться так, как будто на каждую из них тратится не более 1 такта:

Код (Text):

1. такты->     01234567
2. add eax,a   mmma____  ;m - загрузка, a - сложение
3. add eax,a   _mmma___
4. add eax,a   __mmma__

Во-вторых, как уже заметил Pavia, современные процы - это навороченные сперскалярные устройства, которые разбивают команды на элементарные микрооперации (мопы) и могут выполнять их спекулятивно с изменением порядка. В частности команда add eax,a разбивается на два мопа mov tmp,a и add eax,tmp где tmp - это временный внутренний регистр процессора. При этом в реальном потоке команд моп загрузки может быть послан на исполнение значительно раньше, особенно если значение регистра eax еще не готово или АЛУ занято другими операциями:

Код (Text):

1. такты->       01234567
2. add eax,edx   a_______
3. add eax,edx   _a______
4. add eax,edx   __a_____
5. add eax,edx   .__a___
6. add eax,edx   .___a__
7. add eax,a     .mmm_a_ ;<-- загрузка завершается даже раньше чем нужно

Резюме: обычно, за исключением особых случаев (AGI, табличные преобразования), загрузка данных из L1 выполняется параллельно с другими операциями и заметных тормозов не вносит. Причем локальные (стековые) переменые, как правило, всегда находятся в L1, т.к. текущая область стека постоянно используется в операциях push\pop\call

PS: А вообще проблема с нехваткой регистров - надуманная, т.к. за исключением особых случаев 6-7 регистров вполне хватает. Ну а "плохим танцорам" всегда чего-то мешает или не хватает

 

Теперь всё проясняется. А конвееризация вычислений осуществляется за счет нескольких АЛУ да?

 

Нет, несколько АЛУ - это распараллеливание = возможность одновременного вполнения нескольких команд на разных АЛУ.
А конвееризация - это разбивка сложного и соотв-но длительного действия на более мелкие операции. При этом блок, выполняющий это действие, разбивается на подблоки таким образом, что каждый подблок выполняет свою операцию, передает результат следующему подблоку и сам становится готовым начать новую операцию из следующей команды. Например, та же загрузка данных из кэша разбивается на 3 части: "адрес", "запрос", "прием" и соотв-но когда блок адреса закончил вычисление и передал адрес в блок запроса, он тут же может начать вычисление адреса другой команды, не дожидаясь пока данные первого запроса придут из кэша.
Аналогичным образом в проце конвееризуются некоторые вычислительные блоки, например все умножители (целочисленный, FPU и MMX\SSE), поэтому общая задерка умножения сотавляет около 4-5 тактов, но независимые умножения могут поступать на исполнение в каждом такте, т.е. в одном умножителе может одновременно находится до 4-5 команд умножения на разных стадиях обработки.
Быстрые однотактные АЛУ-операции разумеется не конвееризуются (за исключением P4, в котором 0.5 такта на сложение\вычитание достигается за счет конвееризации обработки двух половинок регистра)

 

fluck
основной смысл тут уже вроде сказали - выбросить идею "оптимизация за счет использования только регистров"

дальше если и будет то посты ввиде фрагментов перевода мануалов интела
возьми да сам почитай - там все системно и понятно

 

leo спасибо за доходчивый ответ. Всё ясно