процессор сам меняет местами строки кода, как это возможно? Опции

[TigerSHARC]

https://www.youtube.com/watch?v=SIZmLPtcZiE&t=1112s

начало: 10:24
10:54 - "Хитрый процессор" может взять и переставить инструкции местами.

КАК?

[iosifk]

https://www.youtube.com/watch?v=SIZmLPtcZiE&t=1112s

начало: 10:24
10:54 - "Хитрый процессор" может взять и переставить инструкции местами.

КАК?

Я это видео не смотрел...
Но точно знаю, как делается для Аналоговских DSP.
Значит хитрость вот какая может быть.
Представим:
инстр1
инстр2
инстр3
джамп...

Как это обычно выполняется?
сначала выполняются 3 инструкции, потом делается джамп, А потом несколько тактов процессор стоит, пока не перезагрузится конвейер из нового адреса. При этом в конвейере еще будут инструкции из старого адреса после команды "джамп", но их выполнение будет блокироваться процессором.
А теперь представим, что команду "джамп" компилятор передвинет вперед на то кол-во инструкций, какова глубина конвейера.
Как-то так:
инстр1
инстр2
джамп
инстр3..

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

[@Ark]

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

На сколько мне известно, современные компиляторы "подстраиваются" под конкретный процессор, переставляя инструкции в нужном порядке.
Тем самым, обеспечивается нужный, зачастую "кривой" порядок инструкций, но оптимальный для данного процессора.
В итоге, обеспечивается максимальное быстродействие...

[iosifk]

На сколько мне известно, современные компиляторы "подстраиваются" под конкретный процессор, переставляя инструкции в нужном порядке.
Тем самым, обеспечивается нужный, зачастую "кривой" порядок инструкций, но оптимальный для данного процессора.
В итоге, обеспечивается максимальное быстродействие...

Ну да...
А если там еще есть микро-архитектура, это когда программист думает, что "вот по этому адресу есть регистр общего назначения"... А на самом деле, этих регистров там несколько и только компилятор знает, в каком хранится какое значение от предыдущих шагов программы. Поэтому к таким процессорам ассемблера нет вообще. У Шарков еще был, а у Блэкфинов - уже нет... И что там на самом деле делает процессор - тайна

[jcxz]

А на самом деле, этих регистров там несколько и только компилятор знает, в каком хранится какое значение от предыдущих шагов программы. Поэтому к таким процессорам ассемблера нет вообще. У Шарков еще был, а у Блэкфинов - уже нет...

Если компилятор знает, то будет знать и программист, пишущий на асме. Особых сложностей в этом нет. Ещё больше 10 лет назад писал на асме для TMS320VC5502: и уже там я распараллеливал поток инструкций - держал в голове что например одна инструкция (из пары) у меня выполняется на D-unit АЛУ, а вторая (из пары) - на A-unit АЛУ, поэтому они не должны использовать общие ресурсы (регистры), так как операции для этих разных АЛУ выполняются на разных стадиях конвеера и если будут взаимозависимости, то могут быть штрафы по нескольку тактов (на величину разности по конвееру между фазами исполнения разных инструкций).
Ничего сложного в этом нет. После некоторой практики запоминаешь на какой стадии конвеера выполняется какая инструкции и уже не думаешь в формате "эта инструкция стоит до, значит она выполнится до", а уже глядя на код понимаешь в каком такте после выборки команды она выполнится, и какой будет реальный порядок выполнения.
Но порядок выполнения инструкций при этом в c55xx не меняется - просто если последующая инструкция выполняется на более ранней стадии конвеера чем последующая, то на неё накладывается штраф на время разницы между этими двумя инструкциями. Возможно что в других ядрах как раз не штрафуется, а позволяется выполниться раньше.
Запись значений из регистров в память в ядрах C55xx всегда выполняется строго в одной и той же фазе конвеера. А именно об этом идёт речь в том видео, а не о реальной стадии конвеера на котором выполнится команда! Так что - вне зависимости от точки выполнения на конвеере, данные в память на C55xx всегда пишутся строго в том порядке, в каком стоят команды. Не знаю как с этим обстоят дела на других ядрах...
Но дальше идут кеши и разные регионы памяти, к каждому из которых своя шина, и каждый из которых может быть занят или не занят в этот момент другим bus-master-ом. Вот тут как раз вполне возможно рассогласование времён физической записи в ячейку памяти.