Основы организации вычислительных систем icon

Основы организации вычислительных систем




НазваОсновы организации вычислительных систем
Сторінка1/6
Дата конвертації24.02.2013
Розмір0.72 Mb.
ТипДокументи
  1   2   3   4   5   6
1. /Лекции/GLAVA_7.doc
2. /Лекции/miptexmn.doc
3. /Лекции/АПП_ПОВТ/Cell - единица производительности.doc
4. /Лекции/АПП_ПОВТ/risc-.doc
5. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь1.doc
6. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь10_1.doc
7. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь10_2.doc
8. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь11_1.doc
9. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь11_2.doc
10. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь12.doc
11. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь13_1.doc
12. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь13_2.doc
13. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь14_1.doc
14. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь14_2.doc
15. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь14_3.doc
16. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь15_1.doc
17. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь15_2.doc
18. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь16_1.doc
19. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь16_2.doc
20. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь16_3.doc
21. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь2.doc
22. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь3_1.doc
23. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь3_2.doc
24. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь4_1.doc
25. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь4_2.doc
26. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь5.doc
27. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь6.doc
28. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь7_1.doc
29. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь7_2.rtf
30. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь8_1.doc
31. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь8_2.doc
32. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь8_3.doc
33. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь9_1.doc
34. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Лек ь9_2.doc
35. /Лекции/АПП_ПОВТ/Арх_МногоПроц_ВС/Литература.doc
36. /Лекции/АПП_ПОВТ/Пкп.doc
37. /Лекции/АПП_ПОВТ/Шумаков_Методы оптимизации кода WEB/Лекция 01.rtf
38. /Лекции/Основы организации вычислительных систем(Стукало).doc
39. /Лекции/РП/basics_of_par_prog.pdf
40. /Лекции/РП/standart075500.doc
41. /Лекции/Указатель литературы/2005s12.pdf
42. /Лекции/Указатель литературы/Таненбаум.doc
Основы организации вычислительных систем
Вопросы к экзамену по курсу "Сети и архитектуры эвм"
Cell единица производительности Евгений Патий, "Экспресс электроника", #05/2005
Никита Расторгуев «Экспресс-Электроника»
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектуры и топологии многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Архитектура многопроцессорных вычислительных систем
Программируемый контроллер прерываний I8259A
Лекция множества что такое "множество" ясно из самого слова без всякого определения. Тем более, что дать этому фундаментальному математическому понятию определение невозможно. И не пробуйте
Основы организации вычислительных систем
Образовательный стандарт высшего профессионального образования

 


Основы организации вычислительных систем

Процессоры

Архитектура системы команд. Классификация процессоров (CISC и RISC)


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

Двумя основными архитектурами набора команд, используемыми компьютерной промышленностью на современном этапе развития вычислительной техники являются архитектуры CISC (Complete Instruction Set Computer) и RISC (Reduced Instruction Set Computer).

Основоположником CISC-архитектуры можно считать компанию IBM с ее базовой архитектурой /360, ядро которой используется с 1964
года и дошло до наших дней (IBM ES/9000). Лидером в разработке микропроцессоров c полным набором команд CISC считается компания Intel со своей серией x86 и Pentium. Эта архитектура является практическим стандартом для рынка микрокомпьютеров. Для CISC-процессоров характерно: сравнительно небольшое число регистров общего назначения; большое количество машинных команд, некоторые из них нагружены семантически аналогично операторам высокоуровневых языков программирования и выполняются за много тактов; большое количество методов адресации; большое количество форматов команд различной разрядности; преобладание двухадресного формата команд; наличие команд обработки типа регистр-память.

Основой архитектуры современных рабочих станций и серверов является архитектура компьютера с сокращенным набором команд RISC. Зачатки этой архитектуры уходят своими корнями к компьютерам CDC6600, разработчики которых (Торнтон, Крэй и др.) осознали важность упрощения набора команд для построения быстрых вычислительных машин. Эту традицию упрощения архитектуры С. Крэй с успехом применил при создании широко известной серии суперкомпьютеров компании Cray Research. Однако окончательно понятие RISC в современном его понимании сформировалось на базе трех исследовательских проектов компьютеров: процессора 801 компании IBM, процессора RISC университета Беркли и процессора MIPS Стенфордского университета.

Эти три машины имели много общего. Все они придерживались архитектуры, отделяющей команды обработки от команд работы с памятью, и делали упор на эффективную конвейерную обработку. Система команд разрабатывалась таким образом, чтобы выполнение любой команды занимало небольшое количество машинных тактов (предпочтительно один машинный такт). Сама логика выполнения команд с целью повышения производительности ориентировалась на аппаратную, а не на микропрограммную реализацию. Чтобы упростить логику декодирования команд использовались команды фиксированной длины и фиксированного формата.

Среди других особенностей RISC-архитектур следует отметить наличие достаточно большого регистрового файла (в типовых RISC-процессорах реализуются 32 или большее число регистров по сравнению с 8 - 16 регистрами в CISC-архитектурах), что позволяет большему объему данных храниться в регистрах на процессорном кристалле большее время и упрощает работу компилятора по распределению регистров под переменные. Для обработки, как правило, используются трехадресные команды, что помимо упрощения дешифрации дает возможность сохранять большее число переменных в регистрах без их последующей перезагрузки.

Ко времени завершения университетских проектов (1983-1984 гг.) обозначился также прорыв в технологии изготовления сверхбольших интегральных схем. Простота архитектуры и ее эффективность, подтвержденная этими проектами, вызвали большой интерес в компьютерной индустрии, и с 1986 года началась активная промышленная реализация архитектуры RISC. К настоящему времени эта архитектура прочно занимает лидирующие позиции на мировом компьютерном рынке рабочих станций и серверов.

Развитие архитектуры RISC в значительной степени определялось прогрессом в области создания оптимизирующих компиляторов. Именно современная техника компиляции позволяет эффективно использовать преимущества большего регистрового файла, конвейерной организации и большей скорости выполнения команд. Современные компиляторы используют также преимущества другой оптимизационной техники для повышения производительности: реализацию задержанных переходов и суперскалярной обработки.

Следует отметить, что в разработках компании Intel (Pentium Pro), а также ее последователей-конкурентов широко используются идеи, реализованные в RISC-микропроцессорах, так что многие различия между CISC и RISC стираются. Однако сложность архитектуры и системы команд x86 остается и является главным фактором, ограничивающим производительность процессоров на ее основе.

Конвейерная организация

Простейшая организация конвейера и оценка его производительности

Разработчики архитектуры компьютеров издавна прибегали к методам проектирования, известным под общим названием "совмещение операций", при котором аппаратура компьютера в любой момент времени выполняет одновременно более одной базовой операции. Этот общий метод включает два понятия: параллелизм и конвейеризацию. Хотя у них много общего и их зачастую трудно различать на практике, эти термины отражают два совершенно различных подхода. При параллелизме совмещение операций достигается путем воспроизведения в нескольких копиях аппаратной структуры. Высокая производительность достигается за счет одновременной работы всех элементов структур, осуществляющих решение различных частей задачи.

Конвейеризация (или конвейерная обработка) в общем случае основана на разделении подлежащей исполнению функции на более мелкие части, называемые ступенями, и выделении для каждой из них отдельного блока аппаратуры. Так обработку любой машинной команды можно разделить на несколько этапов или ступеней, организовав передачу данных от одного этапа к следующему. При этом конвейерную обработку можно использовать для совмещения этапов выполнения разных команд. Производительность при этом возрастает благодаря тому, что одновременно на различных ступенях конвейера выполняются несколько команд. Конвейерная обработка такого рода широко применяется во всех современных быстродействующих процессорах.

Для иллюстрации основных принципов построения процессоров мы будем использовать простейшую архитектуру, содержащую 32 целочисленных регистра общего назначения (R0, ... ,R31), 32 регистра плавающей точки (F0,...,F31) и счетчик команд PC. Будем считать, что набор команд нашего процессора включает типичные арифметические и логические операции, операции с плавающей точкой, операции пересылки данных, операции управления потоком команд и системные операции. В арифметических командах используется трехадресный формат, типичный для RISC-процессоров, а для обращения к памяти используются операции загрузки и записи содержимого регистров в память.

Выполнение типичной команды можно разделить на следующие этапы:

  • выборка команды - IF (по адресу, заданному счетчиком команд, из памяти извлекается команда);

  • декодирование команды / выборка операндов из регистров - ID;

  • выполнение операции / вычисление эффективного адреса памяти - EX;

  • обращение к памяти - MEM;

  • запоминание результата - WB.

Для конвейеризации вычислений можно просто разбить выполнение команд на указанные выше этапы, отведя для выполнения каждого этапа один такт синхронизации, и начинать в каждом такте выполнение новой команды. Естественно, для хранения промежуточных результатов каждого этапа необходимо использовать регистровые станции. Хотя общее время выполнения одной команды в таком конвейере будет составлять пять тактов, в каждом такте аппаратура будет выполнять в совмещенном режиме пять различных команд.

Работу конвейера можно условно представить в виде временной диаграммы (рисунок 3.2), на которых обычно изображаются выполняемые команды, номера тактов и этапы выполнения команд.

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

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



Номер команды

Номер такта






1

2

3

4 5 6 7 8 9

Команда I

IF

ID

EX

MEM WB

Команда i+1




IF

ID

EX MEM WB

Команда i+2





IF

ID EX MEM WB

Команда i+3







IF ID EX MEM WB

Команда i+4







IF ID EX MEM WB

Рис. 3.2. Диаграмма работы простейшего конвейера

При реализации конвейерной обработки возникают ситуации, которые препятствуют выполнению очередной команды из потока команд в предназначенном для нее такте. Такие ситуации называются конфликтами. Конфликты снижают реальную производительность конвейера, которая могла бы быть достигнута в идеальном случае. Существуют три класса конфликтов:

  1. Структурные конфликты, которые возникают из-за конфликтов по ресурсам, когда аппаратные средства не могут поддерживать все возможные комбинации команд в режиме одновременного выполнения с совмещением.

  2. Конфликты по данным, возникающие в случае, когда выполнение одной команды зависит от результата выполнения предыдущей команды.

  3. Конфликты по управлению, которые возникают при конвейеризации команд переходов и других команд, которые изменяют значение счетчика команд.

Конфликты в конвейере приводят к необходимости приостановки выполнения команд (pipeline stall). Обычно в простейших конвейерах, если приостанавливается какая-либо команда, то все следующие за ней команды также приостанавливаются. Команды, предшествующие приостановленной, могут продолжать выполняться, но во время приостановки не выбирается ни одна новая команда.
Структурные конфликты и способы их минимизации

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

Другая возможность появления структурных конфликтов связана с недостаточным дублированием некоторых ресурсов, что препятствует выполнению произвольной последовательности команд в конвейере без его приостановки. Например, машина может иметь только один порт записи в регистровый файл, но при определенных обстоятельствах конвейеру может потребоваться выполнить две записи в регистровый файл в одном такте. Это также приведет к структурному конфликту. Когда последовательность команд наталкивается на такой конфликт, конвейер приостанавливает выполнение одной из команд до тех пор, пока не станет доступным требуемое устройство.

Структурные конфликты возникают, например, и в машинах, в которых имеется единственный конвейер памяти для команд и данных (рисунок 3.3). В этом случае, когда одна команда содержит обращение к памяти за данными, оно будет конфликтовать с выборкой более поздней команды из памяти. Чтобы разрешить эту ситуацию, можно просто приостановить конвейер на один такт, когда происходит обращение к памяти за данными. Подобная приостановка часто называются "конвейерным пузырем" (pipeline bubble) или просто пузырем, поскольку пузырь проходит по конвейеру, занимая место, но не выполняя никакой полезной работы.

Команда

Номер такта






1

2

3

4 5 6 7 8 9 10

Команда загрузки

IF

ID

EX

MEM WB

Команда 1



IF

ID

EX MEM WB

Команда 2





IF

ID EX MEM WB

Команда 3







Stall IF ID EX MEM WB

Команда 4







IF ID EX MEM WB

Команда 5







IF ID EX MEM WB

Команда 6







IF ID EX MEM WB

Рис. 3.3. Диаграмма работы конвейера при структурном конфликте

При всех прочих обстоятельствах, машина без структурных конфликтов будет всегда иметь более низкий CPI (среднее число тактов на выдачу команды). Возникает вопрос: почему разработчики допускают наличие структурных конфликтов? Для этого имеются две причины: снижение стоимости и уменьшение задержки устройства. Конвейеризация всех функциональных устройств может оказаться слишком дорогой. Машины, допускающие два обращения к памяти в одном такте, должны иметь удвоенную пропускную способность памяти, например, путем организации раздельных кэшей для команд и данных. Аналогично, полностью конвейерное устройство деления с плавающей точкой требует огромного количества вентилей. Если структурные конфликты не будут возникать слишком часто, то может быть и не стоит платить за то, чтобы их обойти. Как правило, можно разработать неконвейерное, или не полностью конвейерное устройство, имеющее меньшую общую задержку, чем полностью конвейерное. Например, разработчики устройств с плавающей точкой компьютеров CDC7600 и MIPS R2010 предпочли иметь меньшую задержку выполнения операций вместо полной их конвейеризации.
Конфликты по данным, остановы конвейера и реализация механизма обходов

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

Конфликты по данным возникают в том случае, когда применение конвейерной обработки может изменить порядок обращений за операндами так, что этот порядок будет отличаться от порядка, который наблюдается при последовательном выполнении команд на неконвейерной машине. Рассмотрим конвейерное выполнение последовательности команд на рисунке 3.4.

В этом примере все команды, следующие за командой ADD, используют результат ее выполнения. Команда ADD записывает результат в регистр R1, а команда SUB читает это значение. Если не предпринять никаких мер для того, чтобы предотвратить этот конфликт, команда SUB прочитает неправильное значение и попытается его использовать. На самом деле значение, используемое командой SUB, является даже неопределенным: хотя логично предположить, что SUB всегда будет использовать значение R1, которое было присвоено какой-либо командой, предшествовавшей ADD, это не всегда так. Если произойдет прерывание между командами ADD и SUB, то команда ADD завершится, и значение R1 в этой точке будет соответствовать результату ADD. Такое непрогнозируемое поведение очевидно неприемлемо.

ADD

R1,R2,R3



IF

ID

EX MEM WB

SUB

R4,R1,R5





IF

ID EX MEM WB

AND

R6,R1,R7







IF ID EX MEM WB

OR

R8,R1,R9







IF ID EX MEM WB

XOR

R10,R1,R11







IF ID EX MEM WB

Рис. 3.4. Последовательность команд в конвейере и ускоренная пересылка данных
(data forwarding, data bypassing, short circuiting)

Проблема, поставленная в этом примере, может быть разрешена с помощью достаточно простой аппаратной техники, которая называется пересылкой или продвижением данных (data forwarding), обходом (data bypassing), иногда закороткой (short-circuiting). Эта аппаратура работает следующим образом. Результат операции АЛУ с его выходного регистра всегда снова подается назад на входы АЛУ. Если аппаратура обнаруживает, что предыдущая операция АЛУ записывает результат в регистр, соответствующий источнику операнда для следующей операции АЛУ, то логические схемы управления выбирают в качестве входа для АЛУ результат, поступающий по цепи "обхода", а не значение, прочитанное из регистрового файла.

Эта техника "обходов" может быть обобщена для того, чтобы включить передачу результата прямо в то функциональное устройство, которое в нем нуждается.

Конфликты по данным, приводящие к приостановке конвейера

К сожалению не все потенциальные конфликты по данным могут обрабатываться с помощью механизма "обходов". Рассмотрим следующую последовательность команд (рисунок 3.5):

Команда

1

2

3

4 5 6 7 8 9

LW R1,32(R6)



IF

ID

EX MEM WB

ADD R4,R1,R7





IF

ID stall EX MEM WB

SUB R5,R1,R8







IF stall ID EX MEM WB

AND R6,R1,R7







stall IF ID EX MEM WB

Рис. 3.5. Последовательность команд с приостановкой конвейера

Этот случай отличается от последовательности подряд идущих команд АЛУ. Команда загрузки (LW) регистра R1 из памяти имеет задержку, которая не может быть устранена обычной "пересылкой". Вместо этого нам нужна дополнительная аппаратура, называемая аппаратурой внутренних блокировок конвейера (pipeline interloсk), чтобы обеспечить корректное выполнение примера. Вообще такого рода аппаратура обнаруживает конфликты и приостанавливает конвейер до тех пор, пока существует конфликт. В этом случае эта аппаратура приостанавливает конвейер начиная с команды, которая хочет использовать данные в то время, когда предыдущая команда, результат которой является операндом для нашей, вырабатывает этот результат. Эта аппаратура вызывает приостановку конвейера или появление "пузыря" точно также, как и в случае структурных конфликтов.

Методика планирования компилятора для устранения конфликтов по данным

Многие типы приостановок конвейера могут происходить достаточно часто. Например, для оператора А = B + С компилятор скорее всего сгенерирует следующую последовательность команд (рисунок 3.6):

LW R1,В

IF

ID

EX

MEM WB

LW R2,С



IF

ID

EX MEM WB

ADD R3,R1,R2





IF

ID stall EX MEM WB

SW A,R3







IF stall ID EX MEM WB

Рис. 3.6. Конвейерное выполнение оператора А = В + С

Очевидно, выполнение команды ADD должно быть приостановлено до тех пор, пока не станет доступным поступающий из памяти операнд C. Дополнительной задержки выполнения команды SW не произойдет в случае применения цепей обхода для пересылки результата операции АЛУ непосредственно в регистр данных памяти для последующей записи.

Для данного простого примера компилятор никак не может улучшить ситуацию, однако в ряде более общих случаев он может реорганизовать последовательность команд так, чтобы избежать приостановок конвейера. Эта техника, называемая планированием загрузки конвейера (pipeline scheduling) или планированием потока команд (instruction scheduling), использовалась начиная с 60-х годов и стала особой областью интереса в 80-х годах, когда конвейерные машины стали более распространенными.

Пусть, например, имеется последовательность операторов: a = b + c; d = e - f;

Как сгенерировать код, не вызывающий остановок конвейера? Предполагается, что задержка загрузки из памяти составляет один такт. Ответ очевиден (рисунок 3.7):

Неоптимизированная
последовательность команд


Оптимизированная
последовательность команд


LW Rb,b

LW Rb,b

LW Rc,c

LW Rc,c

ADD Ra,Rb,Rc

LW Re,e

SW a,Ra

ADD Ra,Rb,Rc

LW Re,e

LW Rf,f

LW Rf,f

SW a,Ra

SUB Rd,Re,Rf

SUB Rd,Re,Rf

SW d,Rd

SW d,Rd

Рис. 3.7. Пример устранения конфликтов компилятором

В результате устранены обе блокировки (командой LW Rc,c команды ADD Ra,Rb,Rc и командой LW Rf,f команды SUB Rd,Re,Rf). Имеется зависимость между операцией АЛУ и операцией записи в память, но структура конвейера допускает пересылку результата с помощью цепей "обхода". Заметим, что использование разных регистров для первого и второго операторов было достаточно важным для реализации такого правильного планирования. В частности, если переменная e была бы загружена в тот же самый регистр, что b или c, такое планирование не было бы корректным. В общем случае планирование конвейера может требовать увеличенного количества регистров. Такое увеличение может оказаться особенно существенным для машин, которые могут выдавать на выполнение несколько команд в одном такте.

Многие современные компиляторы используют технику планирования команд для улучшения производительности конвейера. В простейшем алгоритме компилятор просто планирует распределение команд в одном и том же базовом блоке. Базовый блок представляет собой линейный участок последовательности программного кода, в котором отсутствуют команды перехода, за исключением начала и конца участка (переходы внутрь этого участка тоже должны отсутствовать). Планирование такой последовательности команд осуществляется достаточно просто, поскольку компилятор знает, что каждая команда в блоке будет выполняться, если выполняется первая из них, и можно просто построить граф зависимостей этих команд и упорядочить их так, чтобы минимизировать приостановки конвейера. Для простых конвейеров стратегия планирования на основе базовых блоков вполне удовлетворительна. Однако когда конвейеризация становится более интенсивной и действительные задержки конвейера растут, требуются более сложные алгоритмы планирования.

К счастью, существуют аппаратные методы, позволяющие изменить порядок выполнения команд программы так, чтобы минимизировать приостановки конвейера. Эти методы получили общее название методов динамической оптимизации (в англоязычной литературе в последнее время часто применяются также термины "out-of-order execution" - неупорядоченное выполнение и "out-of-order issue" - неупорядоченная выдача). Основными средствами динамической оптимизации являются:

  1. Размещение схемы обнаружения конфликтов в возможно более низкой точке конвейера команд так, чтобы позволить команде продвигаться по конвейеру до тех пор, пока ей реально не потребуется операнд, являющийся также результатом логически более ранней, но еще не завершившейся команды. Альтернативным подходом является централизованное обнаружение конфликтов на одной из ранних ступеней конвейера.

  2. Буферизация команд, ожидающих разрешения конфликта, и выдача последующих, логически не связанных команд, в "обход" буфера. В этом случае команды могут выдаваться на выполнение не в том порядке, в котором они расположены в программе, однако аппаратура обнаружения и устранения конфликтов между логически связанными командами обеспечивает получение результатов в соответствии с заданной программой.

  3. Соответствующая организация коммутирующих магистралей, обеспечивающая засылку результата операции непосредственно в буфер, хранящий логически зависимую команду, задержанную из-за конфликта, или непосредственно на вход функционального устройства до того, как этот результат будет записан в регистровый файл или в память (short-circuiting, data forwarding, data bypassing - методы, которые были рассмотрены ранее).

Еще одним аппаратным методом минимизации конфликтов по данным является метод переименования регистров (register renaming). Он получил свое название от широко применяющегося в компиляторах метода переименования - метода размещения данных, способствующего сокращению числа зависимостей и тем самым увеличению производительности при отображении необходимых исходной программе объектов (например, переменных) на аппаратные ресурсы (например, ячейки памяти и регистры).

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

В процессе выполнения программы генерируется множество временных регистровых результатов. Эти временные значения записываются в регистровые файлы вместе с постоянными значениями. Временное значение становится новым постоянным значением, когда завершается выполнение команды (фиксируется ее результат). В свою очередь, завершение выполнения команды происходит, когда все предыдущие команды успешно завершились в заданном программой порядке.

Метод переименования регистров упрощает контроль зависимостей по данным.
Сокращение потерь на выполнение команд перехода и минимизация конфликтов по управлению

Конфликты по управлению могут вызывать даже большие потери производительности конвейера, чем конфликты по данным. Когда выполняется команда условного перехода, она может либо изменить, либо не изменить значение счетчика команд. Если команда условного перехода заменяет счетчик команд значением адреса, вычисленного в команде, то переход называется выполняемым; в противном случае, он называется невыполняемым.

Простейший метод работы с условными переходами заключается в приостановке конвейера как только обнаружена команда условного перехода до тех пор, пока она не достигнет ступени конвейера, которая вычисляет новое значение счетчика команд (рисунок 3.8). Такие приостановки конвейера из-за конфликтов по управлению должны реализовываться иначе, чем приостановки из-за конфликтов по данным, поскольку выборка команды, следующей за командой условного перехода, должна быть выполнена как можно быстрее, как только мы узнаем окончательное направление команды условного перехода.

Команда перехода

IF

ID

EX

MEM WB

Следующая команда



IF

Stall

Stall IF ID EX MEM WB

Следующая команда +1





Stall

Stall Stall IF ID EX MEM WB

Следующая команда +2







Stall Stall Stall IF ID EX MEM

Следующая команда +3







Stall Stall Stall IF ID EX

Следующая команда +4







Stall Stall Stall IF ID

Следующая команда +5







Stall Stall Stall IF

Рис.3.8. Приостановка конвейера при выполнении команды условного перехода

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

  1. Обнаружением является ли условный переход выполняемым или невыполняемым на более ранних ступенях конвейера.

  2. Более ранним вычислением значения счетчика команд для выполняемого перехода (т.е. вычислением целевого адреса перехода).

Снижение потерь на выполнение команд условного перехода

Имеется несколько методов сокращения приостановок конвейера, возникающих из-за задержек выполнения условных переходов. Далее обсуждаются четыре простые схемы, используемые во время компиляции. В этих схемах прогнозирование направления перехода выполняется статически, т.е. прогнозируемое направление перехода фиксируется для каждой команды условного перехода на все время выполнения программы. Позднее будут рассмотрены более мощные схемы, используемые компиляторами (такие, например, как разворачивание циклов), которые уменьшают частоту команд условных переходов при реализации циклов, а также динамические, аппаратно реализованные схемы прогнозирования.

Метод выжидания

Простейшая схема обработки команд условного перехода заключается в замораживании или подавлении операций в конвейере, путем блокировки выполнения любой команды, следующей за командой условного перехода, до тех пор, пока не станет известным направление перехода. Рисунок 3.8 отражал именно такой подход. Привлекательность такого решения заключается в его простоте.

Метод возврата

Более хорошая и не на много более сложная схема состоит в том, чтобы прогнозировать условный переход как невыполняемый. При этом аппаратура должна просто продолжать выполнение программы, как если бы условный переход вовсе не выполнялся. В этом случае необходимо позаботиться о том, чтобы не изменить состояние машины до тех пор, пока направление перехода не станет окончательно известным. В некоторых машинах эта схема с невыполняемыми по прогнозу условными переходами реализована путем продолжения выборки команд, как если бы условный переход был обычной командой. Поведение конвейера выглядит так, как будто ничего необычного не происходит. Однако, если условный переход на самом деле выполняется, то необходимо просто очистить конвейер от команд, выбранных вслед за командой условного перехода и заново повторить выборку команд (рисунок 3.9).

Невыполняемый условный переход

IF

ID EX MEM WB

Команда i+1



IF ID EX MEM WB

Команда i+2



IF ID EX MEM WB

Команда i+3



IF ID EX MEM WB

Команда i+4



IF ID EX MEM WB








Выполняемый условный переход

IF

ID EX MEM WB

Команда (i+1) /целевая команда



IF ID EX MEM WB

Целевая команда +1



stall IF ID EX MEM WB

Целевая команда +2



stall IF ID EX MEM WB

Целевая команда +3



stall IF ID EX MEM

Рис. 3.9. Диаграмма работы модернизированного конвейера

Альтернативная схема прогнозирует переход как выполняемый. Как только команда условного перехода декодирована и вычислен целевой адрес перехода, мы предполагаем, что переход выполняемый, и осуществляем выборку команд и их выполнение, начиная с целевого адреса. Если мы не знаем целевой адрес перехода раньше, чем узнаем окончательное направление перехода, у этого подхода нет никаких преимуществ. Дополнительно в некоторых машинах (особенно в машинах с устанавливаемыми по умолчанию кодами условий или более мощным набором условий перехода) целевой адрес перехода известен раньше окончательного направления перехода, и схема прогноза перехода как выполняемого имеет смысл.

Задержанные переходы

Четвертая схема, которая используется в некоторых машинах называется "задержанным переходом". В задержанном переходе такт выполнения с задержкой перехода длиною n есть:

команда условного перехода

следующая команда 1

следующая команда 2

.....

следующая команда n

целевой адрес при выполняемом переходе

Команды 1 - n находятся в слотах (временных интервалах) задержанного перехода. Задача программного обеспечения заключается в том, чтобы сделать команды, следующие за командой перехода, действительными и полезными. Аппаратура гарантирует реальное выполнение этих команд перед выполнением собственно перехода. Здесь используются несколько приемов оптимизации.

Планирование задержанных переходов осложняется (1) наличием ограничений на команды, размещение которых планируется в слотах задержки и (2) необходимостью предсказывать во время компиляции, будет ли условный переход выполняемым или нет. Статистика для простейшего конвейера с одним слотом задержки перехода при использовании простого алгоритма планирования показывает, что больше половины слотов задержки переходов оказываются заполненными. При этом почти 80% заполненных слотов оказываются полезными для выполнения программы, хотя условные переходы являются выполняемыми примерно в 53% случаев. Высокий процент использования заполненных слотов объясняется тем, что примерно половина из них заполняется командами, предшествовавшими команде условного перехода, выполнение которых необходимо независимо от того, выполняется ли переход, или нет.



Рис. 3.10. Частота заполнения одного слота задержки условного перехода
Проблемы реализации точного прерывания в конвейере

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

Как и в неконвейерных машинах двумя основными проблемами при реализации прерываний являются: (1) прерывания возникают в процессе выполнения некоторой команды; (2) необходим механизм возврата из прерывания для продолжения выполнения программы. Например, для нашего простейшего конвейера прерывание по отсутствию страницы виртуальной памяти при выборке данных не может произойти до этапа выборки из памяти (MEM). В момент возникновения этого прерывания в процессе обработки уже будут находиться несколько команд. Поскольку подобное прерывание должно обеспечить возврат для продолжения программы и требует переключения на другой процесс (операционную систему), необходимо надежно очистить конвейер и сохранить состояние машины таким, чтобы повторное выполнение команды после возврата из прерывания осуществлялось при корректном состоянии машины. Обычно это реализуется путем сохранения адреса команды (PC), вызвавшей прерывание. Если выбранная после возврата из прерывания команда не является командой перехода, то сохраняется обычная последовательность выборки и обработки команд в конвейере. Если же это команда перехода, то мы должны оценить условие перехода и в зависимости от выбранного направления начать выборку либо по целевому адресу команды перехода, либо следующей за переходом команды. Когда происходит прерывание, для корректного сохранения состояния машины необходимо выполнить следующие шаги:

  1. В последовательность команд, поступающих на обработку в конвейер, принудительно вставить команду перехода на прерывание.

  2. Пока выполняется команда перехода на прерывание, погасить все требования записи, выставленные командой, вызвавшей прерывание, а также всеми следующими за ней в конвейере командами. Эти действия позволяют предотвратить все изменения состояния машины командами, которые не завершились к моменту начала обработки прерывания.

  3. После передачи управления подпрограмме обработки прерываний операционной системы, она немедленно должна сохранить значение адреса команды (PC), вызвавшей прерывание. Это значение будет использоваться позже для организации возврата из прерывания.

Если используются механизмы задержанных переходов, состояние машины уже невозможно восстановить с помощью одного счетчика команд, поскольку в процессе восстановления команды в конвейере могут оказаться вовсе не последовательными. В частности, если команда, вызвавшая прерывание, находилась в слоте задержки перехода и переход был выполненным, то необходимо заново повторить выполнение команд из слота задержки плюс команду, находящуюся по целевому адресу команды перехода. Сама команда перехода уже выполнилась и ее повторения не требуется. При этом адреса команд из слота задержки перехода и целевой адрес команды перехода естественно не являются последовательными. Поэтому необходимо сохранять и восстанавливать несколько счетчиков команд, число которых на единицу превышает длину слота задержки. Это выполняется на третьем шаге обработки прерывания.

После обработки прерывания специальные команды осуществляют возврат из прерывания путем перезагрузки счетчиков команд и инициализации потока команд. Если конвейер может быть остановлен так, что команды, непосредственно предшествовавшие вызвавшей прерывание команде, завершаются, а следовавшие за ней могут быть заново запущены для выполнения, то говорят, что конвейер обеспечивает точное прерывание. В идеале команда, вызывающая прерывание, не должна менять состояние машины, и для корректной обработки некоторых типов прерываний требуется, чтобы команда, вызывающая прерывание, не имела никаких побочных эффектов. Для других типов прерываний, например, для прерываний по исключительным ситуациям плавающей точки, вызывающая прерывание команда на некоторых машинах записывает свои результаты еще до того момента, когда прерывание может быть обработано. В этих случаях аппаратура должна быть готовой для восстановления операндов-источников, даже если местоположение результата команды совпадает с местоположением одного из операндов-источников.

Поддержка точных прерываний во многих системах является обязательным требованием, а в некоторых системах была бы весьма желательной, поскольку она упрощает интерфейс операционной системы. Как минимум в машинах со страничной организацией памяти или с реализацией арифметической обработки в соответствии со стандартом IEEE средства обработки прерываний должны обеспечивать точное прерывание либо целиком с помощью аппаратуры, либо с помощью некоторой поддержки со стороны программных средств.
  1   2   3   4   5   6



Схожі:

Основы организации вычислительных систем iconГ. Замковой Теоретические основы безопасности
...
Основы организации вычислительных систем iconЗадание на курсовое проектирование по дисциплине "Основы автоматизированного проектирования сложных систем" на тему
Анализ и синтез звеньев сложных систем в проектной системе компьютерной алгебры Matlab
Основы организации вычислительных систем iconПлан интегрированного урока ( по математике и английскому языку) на тему: «Основы вычислительных операций» выполнили учителя математики и английского языка Криволапова Е. В. Аксёнова Н. В. 2008 год
Тема по английскому языку «English outstanding Scientists» (Выдающиеся учёные Англии)
Основы организации вычислительных систем iconПреодоление первого сдерживающего фактора по широкому использованию параллельных вычислений (высокая стоимость пвс) может быть получено на пути построения кластерных вычислительных систем (clusters)
Пвс, существенно более высокую (по сравнению с последовательным программированием) трудоемкость разработки эффективных параллельных...
Основы организации вычислительных систем iconЛекции по предмету: «Операционные системы вычислительных комплексов». Тема Общие характеристики операционных систем. Понятие про операционную систему
Операционные системы бывают однопользовательские однозадачные ms-dos. Однопользовательские многозадачные Windows 11,95,98 и многопользовательские...
Основы организации вычислительных систем iconВопросы к зачету по дисциплине «Основы систем автоматизированного проектирования»
...
Основы организации вычислительных систем iconПерелік органів з сертифікації (ОС) систем якості (систем управління якістю, систем екологічного управління)
Державний автотранспортний нд I проектний iн-т (державтотрансндiпроект) (мінтранс)
Основы организации вычислительных систем iconМетодические рекомендации по организации деятельности спортивных школ в российской федерации
Едерации по физической культуре и туризму от 25 января 1995 г. N 96-ит о направлении сборника "Нормативно-правовые основы, регулирующие...
Основы организации вычислительных систем iconА. М. Чуйкин основы менеджмента калининград 1996 калининградский государственный университет а. М. Чуйкин основы менеджмента учебное пособие
Чуйкин А. М. Основы менеджмента: Учебное пособие / Калинингр ун-т. Калининград, 1996. 106 с. Isbn 5-230-08823-0
Основы организации вычислительных систем iconОсновы онтологии. СпбГУ. 1997
Основы онтологии: Учеб пособие / Под ред. Ф. Ф. Вяккерева, В. Г. Иванова, Б. И. Липского, Б. В. Маркова. Спб.: Издательство С. Петербургского...
Додайте кнопку на своєму сайті:
Документи


База даних захищена авторським правом ©te.zavantag.com 2000-2017
При копіюванні матеріалу обов'язкове зазначення активного посилання відкритою для індексації.
звернутися до адміністрації
Документи