Основы вычислительных конвейеров, страница 7

2)  обработка событий, асинхронных по отношению к нормальным операциям программы – прерывания; проблема состоит в том, что часто трудно определить

(а) где именно должен быть вставлен форсированный переход

(б) как в точности перезапустить прерванную программу после обработки события, вызвавшего прерывания.

*Программист «чувствует» иногда, что две очень похожие друг на друга программы (последовательности команд) выполняются за существенно разное время.

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

4.2.1. Архитектура конвейерных моделей ОКОД.

Задачу можно сформулировать так: надо поставить на конвейер процесс исполнения машинных команд традиционной архитектуры ОКОД. Сложности: разновидностей такой архитектуры много, команды разнообразны и есть развитие, необходима совместимость и т.д. и т.п.

Приходится вводить абстракцию на этапе анализа и начального проектирования.

Вот базовая модель архитектуры:

·  специальный регистр ЦП, именуемый счетчиком команд, отслеживает положение исполняемой команды;

·  есть несколько других, доступный программисту, регистров ЦП, которые содержат данные (аккумуляторы, индексные, РОНы и проч.);

·  используется двухадресный формат, при котором задаются два операнда, а результат, если таковой есть, помещается на место одного из входных операндов;

·  полный набор команд БП;

·  полный набор команд УП;

·  два размера (два числа разрядов) форматов команд: короткий – для команд RR и в два раза более длинный – для большинства остальных.

При этом многие обычные подробности архитектуры ЦП оставлены без внимания: число регистров, способы адресации, подробные форматы команд. Они пока не столь важны.

Это разбиение типовой команды ADD.

Нечто похожее мы разбирали. Есть нюансы: например, сегмент ENDOP – в нее условно включим микрооперации установки флажков, кода состояния, увеличение содержимого СК,  проверку запросов на прерывание.

Но такое разбиение далеко не единственно возможное:

·  некоторые ступени (выборка операндов) могут реализовываться независимо;

·  часть компонентов ENDOP можно перенести; например, изменение <СК> - в ступень IFETCH;

·  разбить можно менее и более подробно; например, объединить EXEC и SAVE, разбить EAGEN.

Последнее особенно существенно, если применяются очень сложные способы адресации.

А если команда не похожа на простое ADD?

Безусловный переход JUMP имеет еще более простое разбиение, поскольку теперь команда кончается, как только исполнительный адрес ЕА вводится в счетчик команд IC. Действия ENDOP, связанные с завершением, в еще большей степени сокращаются, поскольку здесь не надо обновлять IC.

Однако самые радикальные варианты разбиения встречаются в классе команд условного перехода BRANCH. Здесь в зависимости результата проверки условия, определенного командой, используются два совершенно различных разбиения, причем проверка служит одной из главных фаз исполнения команды. Если проверка дает отрицательный результат, то проверка завершается просто действиями ENDOP, сходными с аналогичными действиями в классе команд запоминания. Если же проверка дает положительный результат, то выбирается разбиение, подобное разбиению команд класса команды безусловного перехода JUMP. Заметим, что всюду в этой главе термины BRANCH, ADD и STORE относятся к командам модели архитектуры, тогда как сами слова – переход, сложение и запоминание – относятся к соответствующим операциям.