Кратко и по делу.
1) RAW‑зависимости (данные)
- I1: LOAD → I2: ADD (R1) — load‑use (I2 читает значение, загружаемое I1).
- I2: ADD → I3: SUB (R3) — обычная ALU→ALU зависимость.
- I3: SUB → I4: BEQ (R5) — зависимость для сравнения.
- I1: LOAD → I5: ADD (R1) — RAW, но расстояние велико (нет проблем после завершения WB).
Разрешение:
- С форвардингом (EX→EX и MEM→EX) обычные ALU→ALU зависимости (I2→I3, I3→I4) снимаются без стажек. Но load‑use (I1→I2) требует 1 такт (классический load‑use stall), поскольку данные из LOAD доступны только после MEM.
- Без форвардинга каждая RAW‑зависимость требует, чтобы потребитель начал ID не раньше, чем WB производителя — это даёт для каждой зависимости задержку IF_потребителя ≥ IF_производителя + 3 (т.е. между инструкциями вставляется 2 пустых такта). Для цепочки I1→I2→I3→I4 это даёт заметную «каскаду» задержек.
2) Управляющие (branch) конфликты
- BEQ (I4) разрешается в EX (в классической 5‑стадийной реализации) — решение ветви доступно только в стадии EX → до этого подряд идут FETCH следующих инструкций. Следовательно при отсутствии предсказания возможен штраф до 2 инструкций (обычно 2‑тактовый штраф — две уже загруженные инструкции нужно сбросить).
- В нашем конкретном потоке после I4 уже была I5 — она будет загружена до разрешения ветви и, если ветвь окажется переходом, потребуется её сброс.
3) Структурные конфликты
- Если память инструкций и данных общая (single‑port unified memory), возможны конфликты IF vs MEM. В приведённом потоке при минимальных задержках встречаются пересечения MEM и IF (например MEM(I1) совпадает с IF(next‑next), и т.д.). Если память раздельная (Harvard), таких конфликтов нет.
4) Число тактов (подход: стандартный 5‑стадийный конвейер, начинаем с IF=1)
- Итого инструкций $n=5$. Теоретически без задержек поток бы занял $n+4=9$ тактов.
- С форвардингом (EX↔EX, MEM→EX) и без структурных конфликтов:
- единственный необходимый stall — load‑use между I1 и I2: добавляется $1$ такт;
- контрольный штраф по ветви (при отсутствии предсказания) — до $2$ тактов (если ветвь неверна). Если считать просто исполнение последовательных инструкций (ветвь не берётся / либо не учитываем штраф), чисто по RAW: количество тактов = $9+1=10$.
- С форвардингом, но при единой памяти (IF/MEM конфликт) в нашем потоке дополнительно возникает по факту примерно $2$ структурных конфликта → ещё $2$ такта. Тогда $10+2=12$.
- Без форвардинга (и при раздельной памяти) — каждая RAW заставляет сдвинуть IF потребителя не менее чем на $+2$ такта по сравнению со следующим подряд IF. Для цепочки это даёт:
- IF_1=1, IF_2≥4, IF_3≥7, IF_4≥10, IF_5≥11 → последний WB в $I{F}_5+4=15$. Итого $15$ тактов.
- Без форвардинга и с unified memory — ещё примерно $2$ структурных конфликта → $15+2=17$.
Итого сводка:
- С форвардингом (separate I/D memory): $10$ тактов (без учёта возможного штрафа ветви).
- С форвардингом (unified memory): $12$ тактов (примерно).
- Без форвардинга (separate memory): $15$ тактов.
- Без форвардинга (unified memory): $17$ тактов.
(Пояснение: учтены только минимальные необходимые stalls; реальная цифра может увеличиться если учитывать штрафы от предположительно неверно предсказанных ветвей.)
5) Рекомендации — эффективная стратегия ветвления и разрешения зависимостей (коротко)
- Ветка: реализовать динамический предиктор (2‑bit BHT) + BTB (для раннего предсказания адреса) — снижает средний штраф ветви с $2$ тактов до близкого к нулю при хорошей предсказуемости.
- Данные:
- Ввести форвардинг (EX→EX, MEM→EX) обязательно — он снимает большинство задержек; оставшийся load‑use можно уменьшить аппаратными средствами (кот. позволяют форвардить результат из MEM в ID/EX) либо сокращать за счёт компиляторных перестановок.
- Компилятор: перепорядочить инструкции (если возможно) — вставить независимую инструкцию между LOAD и её использованием (первичный приём — заполнить «delay slot»).
- Более агрессивно — OoO (out‑of‑order) исполнение / регистровое переименование — снимает каскадные задержки.
- Структура памяти: иметь separate I/D caches (Harvard style) или multi‑ported memory, чтобы избежать IF/MEM конфликтов.
Если нужно, могу показать детальную по‑тактовую таблицу (pipeline diagram) для каждой из четырёх ситуаций.