Форг пишет: 1. Instruction fetching in the Core2 has been improved over previous Intel processors by adding a queue between branch prediction and instruction fetching. This can remove the delay bubble at taken branches in many cases. Unfortunately, the bandwidth is still limited to 16 bytes per clock cycle. The limiting bottleneck is the predecoder, as explained below. Ммм... непонятно, зачем очередь, но ладно, читаем дальше: 2.The instruction decoding machinery is split between a predecoder and a decoder, with a queue in between. The queue has an effective size of 48 or 64 bytes. The purpose of the predecoder is to detect where each instruction begins. Тааак, ещё одна очередь(или буфер? ибо "bytes"), но тут предназначение понятно. Дальше: 3. Fortunately, there is a 64-bytes loop buffer storing predecoded instructions. The predecoded instructions in the loop buffer can be reused in case a branch instruction loops back to an instruction that is still contained in the buffer. Опаньки... Ни разу не ясно где этот буфер находится и как он вписывается в общую картину конвеера (ибо он loop, что означает кольцевой, если я правильно перевёл, и как насчёт его перезаписи следующими по конвееру инструкциями...), но Фог говорит что: 4. Predecoding is therefore not a bottleneck for a small loop that is completely contained in the 64-bytes buffer. It is likely that the loop buffer and the queue between predecode and decode is actually one and the same buffer serving two different purposes. Хм... значит между ними (predecode и decode units) это (см. 2. и 3.) и очередь и буфер одновременно. Выходит что 64 байт вполне достаточно, что бы туда влезал кусок кода (цикл), который ещё не будет перезаписываться инструкциями слудующими за ним? То есть, в это время в BTB будет начало этого же цикла и фетчинг пойдёт(?).... Ммм... эээ... запутался, ребята, хелп плиз.
http://agner.org/optimize/microarchitecture.pdf Core 2 Pipeline -> Instruction fetch and predecoding Или Зеркало со Свином )
Заждались ? Пришлось целый опус наваять, чтобы расставить точки над i )) Вопрос: Как кольцевой буфер связан с очередью, как он вписывается в общую картину конвеера и как насчёт его перезаписи следующими по конвееру инструкциями ? Первый вопрос - элементарный )) Путаница, по моему, происходит от того, что многие не задумываясь представляют себе очередь в виде конвеера или своего рода сдвигового регистра - с одного конца входит, из другого выходит - замечательно выходит ) На самом же деле очередь как раз и реализуется на кольцевом буфере. В частности ROB это ни что иное как кольцевой буфер - мопы преспокойно сидят в нем каждый на своем фиксированном месте, которое им указал аллокатор, и спокойно ждут выхода на "пенсию". А путешествуют по конвееру их двойники-копии. Каждая ячейка буфера имеет бит(ы) статуса свободна\занята. Входное записывающее и выходное считывающе устройство имеют свои указатели на текущую ячейку, в начальный момент эти указатели равны и указывают на некоторую свободную ячейку. При поступлении очередной порции данных входной блок проверяет, что ячейка свободна, записывает в нее данные, устанавливает бит занятости (готовности) и перемещает указатель на след.ячейку. Выходной блок проверяет флаг готовности, читает данные, сбрасывает флаг и перемещает указатель. Если скорости записи и чтения одинаковы, то никакой очереди нет - в одном такте пишем, в следующем считываем из той же ячейки. Если чтение отстает, то очередь начинает нарастать - указатель записи убегает от указателя чтения и может наступить переполнение буфера. Если входной блок при очередной записи обнаруживает, что ячейка занята, значит указатель записи убежал на целый оборот, т.е. буфер переполнен и нужно приостановить запись и ждать пока ячейка не освободится. Если буфер достаточно большой (ROB или очереди планировщиков), а последующие стадии конвеера (исп.блоки) могут работать с большой пиковой скоростью, то на одних отрезках кода очередь может увеличиваться, а на других уменьшаться до нуля, не вызывая переполнения буфера. Отсюда выводы: 1) Кольцевой буфер это и есть способ реализации очереди 2) В общую картину конвеера он вписывается прекрасно По сути очередь предназначена для сглаживания пиковых нагрузок - очередь то увеливается, то уменшается до нуля, но число стадий (тактов) конвеера, необходимых для записи и чтения данных из очереди фиксировано (м.б = 0) и практически не зависит от размера буфера. 3) в кольцевом буфере всегда перезаписывается самая старая ячейка и перед очередной записью в нем хранится вся история предыдущих записей = длине буфера. Теперь возвращаемся к нашим баранам Очередь на 3-4 блока по 16-байт (48 или 64 байта) между предекодером длин и декодером сама по себе полезна и "тут предназначение понятно", если учесть неравномерность скорости декодирования из-за переменной длины инструкций и ограничений на число генерируемых мопов (декодер 4-1-1-1 + микрокод). Остается вопрос как приспособить эту очередь для обработки коротких циклов. В классической архитектуре во главе конвеера стоит BTB - он выдает адрес 16-байтного блока для очередного фетча. Если в предыдущем блоке не было переходов или они предсказываются как несовершаемые (not-taken), то подтверждается загрузка сдедущего блока, который может быть уже загружен или запрошен из кэша префетчером. Если же в пред.блоке есть совершаемый переход (taken), то BTB выдает адрес 16-байтного блока, содержащего метку (target) перехода. При этом последовательное чтение нарушается и требуется как минимум 1 дополнительный такт на загрузку нового блока - для "толстых" циклов это мелочь, а для "тонких" м.б. существенно. Но в PM и Core 2 есть еще одна фишка под названием loop detector - обнаружитель и предсказатель циклов. На каждый jcc назад заводится пара тегов: Count - текущее число совершенных переходов и Limit - число переходов при предыдущем проходе цикла. При каждом переходе Count увеличивается на 1, а при непереходе (т.е. выходе из цикла) переписывается в поле Limit и затем cбрасывается в 0. Таким образом BTB при загрузке очередного блока может определить, что данный переход является циклом (или по Limit > 0, или хотя бы по Count > 0) и что разность адресов jcc и таргета меньше размера буфера. В этом случае BTB может просто остановить загрузку очередных блоков из кэша и пеключиться на схему управления циклическим буфером. Если Count > 0 и расстояние прыжка меньше 64 байт, то нужный блок или уже находится в буфере или находится on-fly на стадии фетча или предекодера и через такт-другой окажется в буфере. Остается только найти его в буфере (например, по прицепленному тегу адреса) и затем эмулировать работу предекодера, устанавливая флаги готовности блоков в буфере, и подправлять указатель считываемого в декодер блока при очередном прыжке. Выход из этого режима реализуется просто - если Limit еще не установлен, то получаем обычную ошибку предсказания со сбросом конвеера и возвратом к фетчу. Если Limit установлен, то тоже просто - на последней итерации (или на предпоследней в завис-ти от размера цикла) запускаем фетчер и устанавливаем указатель предекодера на ниболее старую ячейку - через несколько тактов с предекодера в буфер начнут поступать новые блоки и восстановится обычный режим
