Файл: Мельник А. Архітектура комп\'ютера.doc

Скачать файл
Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 24.12.2021

Просмотров: 6841

Скачиваний: 22

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

198

цьому найменші зміни у конвеєрі вимагають перепроектування компілятора (не зви­чайний, а оптимізуючий), що є надто складною ресурсомісткою та кропіткою працею. Зазначеної проблеми для процесора Crusoe просто не існує. З погляду системних про­грам Crusoe виглядає як стандартний процесор х86.

Описана технологія віртуалізації архітектури комп'ютера зі складною системою ко­манд є принципово новим і ефективним методом декомпозиції та вирішення складних завдань проектування сучасних комп'ютерів. Запропонований фірмою Трансмета про­грамно-апаратний метод проектування забезпечив вдалий розподіл функцій процесора між його програмною та апаратною частинами, і, тим самим, дозволив знайти компро­міс між вартістю та складністю, між продуктивністю та споживаною потужністю.

Програма Code Morphing формування коду КДФК транслює групи команд проце­сора х86, а не кожну відокремлену команду, як у суперскалярному процесорі. Зрозумі­ло, що опрацювання групи команд розширює діапазон дій програмного транслятора, що дає йому можливість враховувати семантику фрагмента коду, разом із притаман­ною фрагментові кореляцією поміж сусідніми командами. Саме це обумовлює перева­гу трансляційної технологій Crusoe. Більше того, суперскалярний процесор транслює команду кожного разу, як її виконує. Crusoe виконує трансляцію команди одноразово, зберігаючи результат трансляції у так званій трансляційній кеш пам'яті. Коли виконан­ня фрагмента програми процесора х86 повторюється, Crusoe не виконує повторну тран­сляцію, а забирає потрібне з трансляційної кеш пам'яті. Зрозуміло, що "компільований" фрагмент коду процесора х86 виконується швидше від "інтерпретованого".

Програмна, а не апаратна, реалізація трансляції відкриває нові можливості. Адже апаратна реалізація складних алгоритмів трансляції збільшує кількість транзисторів на кристалі та споживану потужність. Crusoe виконує лише одноразову повільну трансля­цію при першому проході програми, а всі наступні проходи здійснює швидко, що дозво­ляє значно підвищити складність та ефективність програмно реалізованих алгоритмів трансляції, підвищивши тим самим характеристики комп'ютерної системи.

Зрозуміло, що програма Code Morphing використовує властивість локалізації (local­ity of reference) вибирань програмних кодів будь-якої універсальної машини. Апаратура процесора Crusoe опрацьовує отриманий від Code Morphing молекулярний код не хао­тично, а впорядковано, за природною чергою. Це гарантує впорядковане опрацювання оригінальних команд процесора х86. Саме молекули однозначно визначають паралелізм рівня машинних команд, тому апаратна реалізація процедури паралельного опрацюван­ня спрощується.

5.8. Комп'ютери з явним паралелізмом виконання команд

Як ми вже побачили з матеріалу даного розділу, планування порядку обчислень є досить важким завданням, яке доводиться вирішувати при проектуванні сучасного комп'ютера. У суперскалярній архітектурі для розпізнавання залежностей між команда­ми застосовуються досить складні апаратні рішення (наприклад, в Р6 і наступних про­цесорах фірми Intel для цього використовується буфер перевпорядковування команд - Reorder Buffer). Проте розміри такого апаратного планувальника при збільшенні кіль­кості функціональних пристроїв зростають в геометричній прогресії. Тому суперскалярні

199

проекти зупинилися на відмітці 5-6 оброблюваних за цикл команд. Навіть КДФК теж далеко не завжди можуть забезпечити повне заповненням в'язанок команд - реальне завантаження близько 6-7 команд в такті.

Вище зазначені проблеми призначена вирішувати нова архітектура із назвою EPIC (Explicitly Parallel Instruction Set Computing).

Класичний процесор, переважно, не спроможний визначити взаємовплив (залеж­ності даних, керування і структури) поміж віддаленими командами первинного (поки що не розпаралеленого) потоку команд. Адже процесор аналізує лише той фрагмент по­току команд, що розташований безпосередньо у процесорному апаратному, тому і не­великому, буфері команд. З іншого боку, програма-компілятор виконуваного коду має значно ширше поле зору та практично необмежений час (ще до виконання програми процесором), аби наперед проаналізувати первинний програмний код на предмет ви­явлення вказаних вище залежностей та оптимізувати цей код під потрібну архітектуру. В цілому, тут ми маємо ситуацію, коли бажано все, що можна, підготувати заздалегідь (зрозуміло, статично, під час компіляції), а не приймати складних апаратних динамічних рішень в реальному часі (при виконанні процесором вже остаточно скомпільованої про­грами, із притаманними швидкими рішеннями, помилками та з відповідними часовими витратами на їх виправлення).

Архітектура EPIC передбачає пряме розпаралелювання виконання програми, тобто компілятор мусить повідомляти процесор про те, яка частина коду може виконуватися паралельно. Оптимізований за попереднім означенням компілятор EPIC аналізує про­грамний код, аби визначати, де та коли відбудуться/не відбудуться умовні переходи та знайти і позначити ті частини програмного коду, які можна виконувати паралельно.

Прикладом процесора з архітектурою EPIC є процесор ІА-64 фірми Intel. В цьому процесорі команди, як і в архітектурі КДСК, пакуються компілятором в 128-розрядні в'язанки команд. Кожна в'язанка команд процесора ІА-64 містить три команди та ша­блон, як це показано на рис. 5.30.

В шаблоні вказується залежність між командами в одній в'язанці та між в'язанками, тобто вона вказує, чи можна одночасно виконувати і-ту (і= 0,1,2) команду в'язанки m од­ночасно з j-ю (j= 0,1,2) командою в'язанки п. Кожній в'язанці в процесорі виділяється три функціональних пристрої, тобто кожній команді виділяється один пристрій. Вміст поля шаблону встановлюється або при генеруванні коду компілятором, або безпосередньо системним програмістом, що пише мовою асемблер. Процес генерації коду виконують так, аби гарантовано позбутися конфліктів типу RAW, WAW в межах командної групи.

Кожна з трьох команд в'язанки має формат, приведений на рис. 5.31.

200

До складу команди входять наступні поля: коду операції, предиката, номери регістрів двох операндів та регістра результату. Розрядності кожного поля вказані на рисунку.

Поле предиката вказує номер регістра предиката, яких в процесорі є 64. Предикація - це спосіб обробки умовних переходів. В процесорі ІА-64 виконуються обидві вітки переходу. Суть способу предикації полягає в наступному. Командам різних гілок одного умовного переходу виділяються різні регістри предиката. Ці команди виконуються на функціональних пристроях процесора, а їх результати записуються до пам'яті тільки після визначення вмісту регістрів предиката, тобто після обчислення умови переходу. Вмісту регістрів вітки переходу, якій відповідає умова переходу, присвоюється значення і, а вмісту регістрів вітки переходу якій не відповідає умова переходу присвоюється значення 0. Процесор перевіряє вміст регістрів предикату і записує в пам'ять результати тільки тих команд, які вказують на регістри предикатів з одиничним вмістом.

Архітектура ІА-64 підвищує рівень паралельного виконання команд за рахунок того, що вона дозволяє на рівні мови асемблер прямо вказувати на паралелізм, реалізує в'я­занки, кожна з яких містить три виконувані команди та містить множину надлишкових програмно-недосяжних регістрів, що дублюють операнди поточних команд, запобіга­ючи тим самим завчасному перезапису цих операндів.

5.9. Короткий зміст розділу

Розглянуті конфлікти в конвеєрі команд та методи їх усунення, оскільки вони знижу­ють продуктивність конвеєра, яка могла б бути досягнута в ньому в ідеальному випадку. Більше того, конфлікти можуть звести нанівець всі затрати на створення конвеєра ко­манд. Проведено аналіз методів запобігання трьом класам конфліктів: структурних, які виникають з причини браку ресурсів, коли апаратні засоби не можуть підтримувати всі можливі комбінації команд в режимі одночасного виконання з перекриттям, конфліктів за даними, що виникають у разі, коли виконання наступної команди залежить від ре­зультату виконання попередньої команди, та конфліктів керування, які виникають при конвеєризації команд передачі керування, які змінюють значення лічильника команд. Наведено приклади структур конвеєрних процесорів, у яких зменшено ймовірність ви­никнення конфліктів.

Розглянуто особливості запобігання конфліктам в суперскалярних процесорах, які є наступним кроком в побудові високопродуктивних процесорів. Суперскалярний про­цесор має кілька функціональних блоків і виконує кілька команд за один такт, тобто в такому процесорі одна команда виконується менще як за один такт. Прикладами супер­скалярних процесорів є PowerPC фірми IBM, UltraSparc фірми Sun, Alpha фірми DEC. Але методи запобігання конфліктам в таких процесорах є ще складнішими, ніж у конве­єрних процесорах, що вимагає відповідного ускладнення апаратних засобів.

Були розглянуті архітектури комп'ютерів, в яких відсутні конфлікти команд, а саме: комп'ютери з довгим форматом команди, а також комбіновані архітектури, в яких по­єднано архітектури КПСК та КДФК.

Проблеми забезпечення динамічного планування виконання команд привели роз­робників до архітектури комп'ютера з явним паралелізмом EPIC, прикладом якої ста­ла розробка ІА-64 фірми Intel. Комп'ютери цієї архітектури опрацьовують паралельно в'язанку команд, яка вказує декілька операцій, що можуть виконуватися паралельно.

201

Система команд цієї архітектури тісно пов'язана з будовою компілятора, оскільки пла­нування паралельного виконання команд тут покладено на компілятор, який здійснює цю роботу перед виконанням програми в комп'ютері.

Для зменшення впливу умовних переходів на продуктивність конвеєра в процесо­рі ІА-64 введено предикатні команди. В цьому процесорі всі команди виконуються, але результати їх виконання записуються до регістрового файла лише тоді, коли розряд пре­диката рівний 1. Результатом є те, що не потрібно зупиняти конвеєр до вияснення умови переходу, хоча виконується більша кількість команд.

5.10. Література для подальшого читання

Конфлікти в конвеєрі команд та методи їх усунення розглянуті в роботах [7, 8, 13, 14, 16, 18—21]. В роботах [3, 4, 30-33] проведено аналіз методів запобігання трьох класів кон­фліктів: структурних, конфліктів за даними та конфліктів керування. Опис симулятора WinDLX є на web-сторінці www.

В роботах [9, 10, 22-26] розглянуто особливості запобігання конфліктам в суперска-лярних процесорах. Для аналізу особливостей реалізації засобів запобігання конфлік­там в суперскалярних процесорах PowerPC фірми IBM, UltraSparc фірми Sun, Alpha фір­ми DEC та інших доцільно пошукати їх описи на web-сторінках цих фірм. Використання розподіленої буферної пам'яті (вікна команд) для перевпорядкування команд запропо­новано в роботах [1, 27].

Обмеження паралелізму рівня команд проаналізовано в [28, 29]. В роботах [3, 5, 6, 12, 15] детально розглянуті архітектури комп'ютерів, у яких відсутні конфлікти команд, а саме комп'ютерів з довгим форматом команди. Зокрема в роботі [2] розглянуті питан­ня побудови перших процесорів обробки сигналів АР-120В фірми FPS з архітектурою КДФК. Принципи побудови компіляторів КДФК можна знайти в [4, 11, 17].

Інформацію про комбіновані архітектури, в яких поєднано архітектури КПСК та КДФК, можна знайти в [5].

Архітектура комп'ютера з явним паралелізмом EPIC описана в [7].

5.11. Література до розділу 5

  1. Anderson, D. W., F. J. Sparacio, and R. M. Tomasulo [1967]. "The IBM 360 Model 91: Processor philosophy and instruction handling", IBM J. Research and Development 11:1 (January), 8-24.

  2. Charlesworth, A. E. [1981]. "An approach to scientific array processing: The architecture design of the AP-120B/FPS-164 family", Computer 14:12 (December), 12-30.

  3. COLWELL, R. P., R. P. NIX, J. J. O'DONNELL, D. B. PAPWORTH, AND P. K. RODMAN [1987]. "A VLIW architecture for a trace scheduling compiler", Proc. Second Conf. on Architectural Support for Programming Languages and Operating Systems, IEEE/ACM (March), Palo Alto, Calif., 180-192.

  4. Ellis, J. R. [1986]. Bulldog: A Compiler for VLIW Architectures, MIT Press, Cambridge, Mass.

  5. FISHER, J. A. [1981]. "Trace scheduling: A technique for global microcode compaction", IEEE Trans, on Computers 30:7 (July), 47^t90.

  6. FISHER, J. A. [1983]. "Very long instruction word architectures and ELI-512" Proc. Tenth Symp­osium on Computer Architecture (June), Stockholm, 140-150.

  7. Fisher, J. A. and S. M. Freudenberger [1992]. "Predicting conditional branches from previous runs of a program", Proc. Fifth Conf. on Architectural Support for Programming Languages and Operating Systems, IEEE/ACM (October), Boston, 85-95.

Смотрите также файлы