Конечно, и call тоже Ведь прежде чем предпринять какие-то действия проц должен "увидеть" инструкции jmp\call\ret, а для этого требуется загрузить очередной 16-байтный блок кода из кэша, выполнить разметку границ инструкций декодером длин и начать параллельное декодирование инструкций и формирование мопов. На все это дело уходит не менее 5 стадий (тактов) конвеера. Поскольку эта часть конвеера работает непрерывно, то когда на выходе декодера обнаруживается безусловный переход jmp\call\ret, которого еще нет в BTB, то за ним на разных стадиях обработки может находиться еще куча инструкций (для 3-х канального декодера до 4*3 простых DirectPass инструкций), которые разумеется нужно выбросить\проигнорировать и начать грузить блок кода по новому адресу перехода. Если адрес перехода известен (прямые jmp\call и jcc назад - static prediction for loops), то проц сразу дает команду на загрузку нового блока кода и "сбрасывает" мусор, застрявший на стадиях fetch-decode (видимо просто блокирует выходы декодеров на несколько тактов, не пропуская "мусорные" команды на дальнейшую обработку). Поэтому при первом проходе на инструкциях прямых переходов возникает задержка (пенальти) порядка 6 тактов (длина конвеера до выхода декодера + 1 такт на определение и смену адреса загрузки нового блока). Это же относится и к "нормальному" ret - хотя его адрес формально не известен (берется из стека на этапе исполнения), но в современных процах используется предсказание адреса возврата ret по адресу предыдущего call. При каждом call в спецбуфер (RSB - return stack buffer или RAS - return address stack) заносится адрес следующей за call инструкции, а при каждом ret извлекается последний адрес и осуществляется спекулятивный переход не дожидаясь реального исполнения ret (поэтому рекомендуется соблюдать парность call\ret и не увлекаться разными "фишками", сбивающими с толку процессор). При первом проходе косвенного jmp\call или при ошибке предсказания при повторных проходах реальный адрес перехода становится известен только на стадии исполнения, поэтому задержка (штраф) в тактах составляет не менее полной длины конвеера от fetch до exec. Если при этом в ROB попали команды, следующие за переходом, то все они ес-но сбрасываются. Уточнение\дополнение к вопросу rei3er: Команды, предшествующие переходу, просто обязаны выполниться и уйти в отставку до того как проц начнет декодировать команды по новому адресу. Это связано с тем, что из-за ошибки предсказания и попадания в ROB неверных команд состояние таблицы RAT становится инвалидным. Поэтому вместо того, чтобы пытаться раскручивать состояние регистров назад, проц просто ждет ухода всех предшествующих команд в отставку и записи всех данных в перманентные регистры, и затем просто устанавливает индексы RAT на эти регистры. В результате, как отмечается в манах, штраф на непредсказанных переходах м.б. больше, если им предшествуют тормозные инструкции с большой латентностью.
может ты знаешь формат элемента RAT? (просто интересно) я так полагаю, это значение, описывающее отображение номера логического регистра на номер перманентного регистра т. е что-то вроде XYb, где X, Y - двоичное представление номера например, если перманентных регистров 100, а логических (временных) 50, то общий размер элемента RAT будет равен 7 + 6 = 13 разрядов (2^7 >= 100, 2^6 >= 50) я прав?
Так скажем, не совсем Во первых надо разобраться с терминологией. Логические регистры, они же "архитектурные" это eax, ebx и т.д., включая eflags и системные. Их кодировка по видимому совпадает с кодировкой поля reg в ModR/M c соответствующими битами расширения групп регистров GP\MMX\XMM\DR (в P6 еще различаются AL,AH,AX и EAX, а в P4 и атлонах это части одного EAX). Перманентные регистры - это физические регистры процессора, в которых сохраняется состояние логических регистров на момент отставки инструкций. Соответсвенно контекст потока на момент прерывания\исключения и т.п. берется из перманентых регистров процессора. Для каждой команды, изменяющей операнд-приемник назначается временный регистр из "регистрового файла" RF для сохранения результата. Когда команда уходит в отставку этот результат либо явно переписывается из временного регистра в перманентый (в P6), либо этот временный регистр и становится "перманентным" (в P4 - используется доп.таблица индексов перманентных регистров RF). Соответсвенно в завис-ти от реализации перманентные регистры либо являются логическим продолжением RF (как в P6), либо непосредственно отображаются на временные регистры RF (как в P4). В обоих случаях для временных и перманентных регистров используется общий индекс их положения в RF. Из этого следует, что RAT это просто массив из N индексов RF, где N - число логических регистров процессора. Разрядность индекса определяется общим числом регистров в RF, включая перманентные. При загрузке контекста потока, возврата из прерываний, ошибках предсказания переходов и т.п. все индексы RAT устанавливаются = индексам перманентных регистров (они либо фиксированы как в P6, либо копируются из таблицы индексов перманентых регистров как в P4). Далее когда на стадию RAT поступает моп, например add eax,ebx по логическим индексам eax и ebx из RAT извлекаются соответсвующие им индесы RF, например 7 и 11, затем выбирается свободный регистр RF, например 15, все эти 3 индекса записываются в моп и затем значение RAT по логич.индексу eax заменяется на новое значение 15. Cоответсвенно следущий моп, обращающийся к eax, уже будет брать значение из 15-го регистра RF. Ну и т.д. В случае ошибки предсказания перехода RAT "рассинхронизируется" из-за мусорных инструкций, поэтому проц ждет завершения всех мопов, предшествующих переходу и устанавливает все индексы RAT на перманентные регистры.
пардон, из временных регистров? и чем тогда отличаются временные и перманентные регистры, кроме сохранения состояния регистра на момент отставки инструкции?
а если следующая микрооперация, использующая eax, будет выполнена раньше данной микрооперации (а такое может быть в случае out-of-order) тогда входное значение eax для нее будет невалидным, т. к результата выполнения add eax, ebx еще нет как эта ситуация разруливается?
rei3er Эта ситуация разруливается раньше, на уровне планировщика, если не ошибаюсь. Однако есть классический контрпример - NetBurst и работа с операндами в памяти. Планировщик в этом случае закладывается на расположение данных в кеше первого уровня, если не так - микрооперация уходит на перезапуск.
т. е перед выполнением микрооперации идет проверка наличия микрооперации, которая в качестве одного из входных операндов принимает выходной операнд этой микрооперации, но былп помещена в ROB позже нее? тогда возникает вопрос о структуре элемента ROB: входные и выходные операнды представляют собой значения или ссылки на другие объекты (скажем, перманентные регистры)?
t00x В P6 это разные регистры - в момент отставки мопа происходит копирование значения из временного регистра в перманентный. В P4 один общий регистровый файл RF и две таблицы переименования - одна классическая RAT на входе ROB и одна "на выходе". В момент отставки мопа значение временного регистра никуда не копируется и просто в выходную таблицу записывается индекс этого "временного" регистра. Т.е. в P4 перманентные регистры это просто набор (подмножество) регистров RF, соответствующих логическим регистрам eax,ebx... на момент отставки инструкции rei3er Зависимости разруливаются с помощью флага готовности, который устанавливается в мопе (записи ROB) и соответствующем регистре RF при выполнении операции. Планировщик перед отправкой мопа на исполнение проверяет флаг готовности входных регистров - если готовы, то отправляет моп на исполнение и удаляет его из своей очереди, если нет, то берет следующий моп и т.д. (По видимому для простых операций с малой фикс.латентностью флаг готовности регистра устанавливается с упреждением в самом планировщике, что позволяет выпускать зависимые мопы друг за другом без задержки и использовать схему непосредственной подачи операндов с выхода АЛУ на вход не дожидаясь их записи в RF). Наиболее просто ROB\RF реализованы в P6 (и видимо в атлонах тоже) - в них ROB и RF физически разделены, но их записи логически "склеены" между собой: число регистров RF равно числу записей ROB (плюс перманентные регистры, являющиеся продолжением RF) и каждому мопу назначается регистр с индексом, равным индексу мопа в ROB. Поэтому логически образуется одна расширенная запись - сам моп, результат его выполнения и единый флаг готовности. PS: Схема простая и удобная, но при отставке инструкций требует перезаписи значений регистров в перманентные регистры. Чтобы избавиться от этой перезаписи в P4 замутили полностью независимые ROB и RF с доп.таблицей переименования регистров, "поиском свободного регистра" ROB и т.п. Но видимо эти "замуты" не прижились и в Core 2 использована классическая схема с "жесткой" привязкой индексов ROB и RF
так а что храниться в элементе ROB: значения входных операндов или ссылки на значения операндов (индексы в RF)?
leo понятно, т.е. на P4 на момент отставки инструкции происходит очередное "переименование регистра" из временного в перманентный и для этого "переименования" используется поля таблицы RF. а таблица RF распространяется на все регистры процессора или только на РОНы?
t00x На все РОНы, MMX, XMM, сегментные и флаговые -точно. Остальные не уверен, но не думаю. Смысл извращаться для CRx и DRx? При чем для AMD регистр флагов - это несколько регистров, а для Intel - один, что порой доставляет некоторые неприятности.
rei3er Конечно индексы, т.к. значения регистров хранятся в RF и на одно значение может ссылаться несколько мопов (элементов ROB). При исполнении мопа, изменяющего регистр, например EAX = RF[j], достаточно устанавить флаг готовности регистра RF[j], после чего планировщик может посылать на исполнение любые мопы, ссылающиеся на RF[j]. PS: Все значения регистров хранятся в RF (временные) или RRF (перманентные). Но т.к. в P6 индекс мопа в ROB совпадает с индексом регистра-приемника RF, то это дает основание считать, что значение регистра-приемника (результат операции) хранится в самом элементе ROB. Считать конечно "можно, но только осторожно", т.к. это может привести к путаннице и неверным выводам. Например, и раздельчик ROB read у А.Фога можно понять неоднозначно, а в статье Dark_Master-а и вовсе делается неверный вывод о "хранении операндов микрооперации в самой микрооперации", что конечно не соответствует действительности. Моп "тихо-мирно" сидит в ROB со стадии RAT\Allocate до retire. До того как моп попадет в планировщик значения его операндов еще не известны, а после исполнения операнды-источники уже нафиг никому не нужны, поэтому хранить пару неизвестных\ненужных 80-128 битных значений в самом мопе просто бессмысленно. Поэтому значения входных операндов читаются и связываются с мопом только на стадиях планирования и исполнения и затем ес-но выбрасываются, сохраняется только результат операции и флаги.
