У меня есть один вопрос о процессоре с использованием конвейерной обработки.
Может ли процессор с конвейером команд работать без обнаружения опасности?
-1
1 ответ
0
Конвейерный процессор может избежать всего оборудования для обнаружения угроз, никогда не создавая опасности (возможно, с помощью составления расписаний компилятора) или обрабатывая обнаружение нарушений в программном обеспечении.
Для простого скалярного конвейера структурные опасности относительно легко избежать, нужно только убедиться, что между этапами нет общего оборудования. Это подразумевает инструкции с одним циклом или полностью конвейерное выполнение.
В MIPS R2000 не было никаких структурных опасностей, за исключением, возможно, умножения и деления (поскольку можно было бы прочитать результат перед началом другого умножения или деления, неясно, можно ли считать отсутствие конвейерной обработки этих операций структурной опасностью быть обнаруженным аппаратно). Если рассматривать выбор пути пересылки как не обнаруживающий опасность данных из-за отложенной доступности результата в файле регистра, то MIPS R2000 обнаружил только опасность данных, связанную с доступом к памяти, умножением и делением. Для R2000 требовалось программное обеспечение, чтобы поместить nop в слот задержки загрузки, но аппаратное обеспечение обнаружило и обработало опасность потери данных в кеше.
Если бы умножение было реализовано с задержкой в два цикла, было бы разумно потребовать, чтобы компилятор вставил nop (когда переход из HI или LO в противном случае немедленно следовал бы инструкции умножения или деления или, если эти инструкции использовали регистр общего назначения для пункта назначения, когда этот GPR использовался в качестве источника) для управления этой опасностью данных. Для микроконтроллера было бы невозможно иметь кэши. Это оставило бы только связанный с памятью ввод-вывод в качестве источника опасностей данных. Некоторые встроенные периферийные устройства в микроконтроллере могут поддерживать очень короткую фиксированную задержку, которая может обрабатываться с помощью интервалов задержки (и число интервалов задержки может отличаться от реального доступа к памяти, если компилятор / программист может различить эти два случая) ,
(Обнаружение опасности данных из-за пропуска кеша довольно естественно, так как процессор все равно должен обнаруживать пропадание кеша). Обработка опасности является более сложной.)
Для процессора также было бы возможно обработать задержку всех операций как два цикла (как нагрузки на кеш в R2000). Компилятор будет отвечать за вставку инструкций (возможно, nops) в слоты задержки для инструкций. Если бы процессор был настоящим процессором с бочкообразным движением, циклически проходящим сквозь нити, такие как шесты на стволе, то для операций, выполняющих столько циклов, сколько было бы "стволовых стволов", можно было бы обеспечить кажущуюся задержку за один цикл; неактивный поток эффективно вставляет nops в слоты задержки.
При использовании простых конвейеров компилятор может представлять некоторые структурные опасности и избегать их. Например, процессор может иметь два банка регистров с одним портом чтения в каждом; компилятор должен был бы полностью избежать конфликтов между банками для двух инструкций источника, возможно, вставив инструкции копирования регистра, сделав значение доступным в обоих банках.
Аналогичным образом, программное обеспечение может справляться с опасностями данных, когда наихудшая задержка слишком велика, чтобы просто использовать временные интервалы задержки через спин-цикл, который опрашивается на предмет готовности. (Состояние готовности может предоставляться аппаратным обеспечением или обнаруживаться по значению результата, если гарантируется, что результат не будет иметь конкретного значения, невозможное значение результата может быть заранее вставлено в регистр назначения операции с большой задержкой. Наличие аппаратного обеспечения, обеспечивающего состояние готовности, но не имеющего возможности использовать такое состояние для обнаружения опасностей, кажется глупым, но такое было бы возможно.)
Крупнозернистая многопоточность - еще один способ справиться с большей задержкой. Программное обеспечение может указать процессору переключать потоки, когда задержка в худшем случае будет нецелесообразно скрывать. Если программное обеспечение гарантирует, что частота повторения таких операций с более длительной задержкой является достаточно низкой, два потока могут скрыть задержку, которая в противном случае создала бы опасность для данных. (Я бы посчитал это обнаружением опасности, если аппаратно переключать потоки всякий раз, когда такие операции были декодированы, даже если программное обеспечение должно было гарантировать достаточно низкую частоту повторения.)