2.5. Связь между компилятором и процессором

Архитектура Itaniumобеспечивает такие механизмы как шаблоны инструкций, подсказки (hint) переходов и кэш-подсказки позволяющие компилятору передавать процессору информацию из процесса компиляции. Дополнительно, это позволяет компилировать код для руководства устройствами процессора, использующими информацию в процессе выполнения. Эти коммуникационные механизмы необходимы для минимизации потерь производительности связанных с переходами и кэш-промахами.

Затраты на переходы минимизируются с помощью разрешающего кода передающего информацию перехода на аппаратные средства до фактического выполнения перехода.

Каждая загрузка или выгрузка из памяти имеет двухбитное поле кэш-подсказки, в которое компилятор кодирует его предсказания пространственного и/или временного местоположения области памяти, к которой будет обращение. Процессор, основывающийся на архитектуре Itanium, может использовать эту информацию для определения положения строк кэша в иерархии кэша для улучшения использования. Это особенно важно, поскольку ожидается, что стоимость кэш-промахов будет возрастать.

2.6. Спекулятивность

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

2.6.1. Спекулятивность по управлению

Спекулятивность по управлению – это выполнение операции до перехода на ветвь программы, содержащую эту команду. Рассмотрим следующую последовательность кода:

if (a>b) load (ld_addr1,target1)

else load (ld_addr2,target2)

Если операция load (ld_addr1,target1)была выполнена предварительно, до завершения проверки (a>b), то операция будет спекулятивной по управлению по отношению к управляющему условию (a>b). При нормальном выполнении операцияload (ld_addr1,target1)может быть выполнится, а может быть и нет. Если новая спекулятивная загрузка по управлению явится причиной исключения, то исключение будет обслуживаться, только если (a>b). Когда компилятор использует спекуляцию по управлению, он оставляет операцию проверки на своем месте. Проверка проверяет, произошло ли исключение и если да, то переходит к восстанавливающему (recovery) коду. Теперь последовательность кодов преобразуется примерно так:

/* до критического пути */

sload (ld_addr1,target1)

sload (ld_addr2,target2)

/* кроме операторов использующих target1/target2 */

if (a>b) scheck (target1, recovery_addr1)

else scheck (target2, recovery_addr2)

2.6.2. Спекулятивность по данным.

Спекулятивность по данным – это выполнение загрузки из памяти до сохранения, которое предшествовало ему, и которое может потенциально изменить ее. Спекулятивная загрузка данных также упоминается как «предварительная загрузка» (“advancedload”). Рассмотрим следующую последовательность кода:

store(st_addr,data)

load (ld_addr,target)

use (target)

Процесс определения времени вычисления взаимоотношения между обращениями к памяти называется снятием неопределенности (disambiguated). Если в приведенном примере не может быть снята неопределенность междуst_addr и ld_addr, и если загрузка была выполнена ранее сохранения, то это будет спекулятивная загрузка по данным относительно сохранения. Если адреса памяти накладываются друг на друга, то спекулятивная загрузка данных запущенная раньше сохранения, вернет значение, отличающееся от того, которое было бы при нормальном запуске загрузки после сохранения. Поэтому, по аналогии со спекулятивностью по управлению, когда компилятор спекулятивно делает загрузку данных, то на первоначальное место загрузки вставляется инструкции проверки. Проверка проверяет, произошло ли наложение и если это так, то обращается к восстанавливающему коду.Теперь последовательность кодов преобразуется примерно так:

/* до критического пути */

aload (ld_addr,target)

/* кроме операторов использующих target */

store (st_addr,data)

acheck(target,recovery_addr)

use (target)