Архітектура системи команд
Матеріал з Вікіпедії — вільної енциклопедії.
АРХІТЕКТУРА СИСТЕМИ КОМАНД електронної обчислювальної машини - складова частина архітектури ЕОМ, яка включає інформацію про:
- набір машинних команд - перелік та семантику операцій, які здатна виконувати обчислювальна машина
- доступні регістри - внутрішні комірки пам'яті центрального процесора (пристрою, який виконує обробку інформації), їх функціональне призначення, розрядність, кількість тощо.
- розрядність та формати операндів - об'єктів, над якими виконуються операції
- способи адресації пам'яті - методи доступа до операндів, які зберігаються в пам'яті
- особливості обробки виключних ситуацій (переривань)
Зміст |
[ред.] Еволюція архітектур системи команд
[ред.] Перші акумуляторні архітектури
Набір операцій перших ЕОМ з програмою, яка зберігається в пам'яті, складався з одного-двох десятків команд. Всі операції з інформацією зазвичай виконувались в спеціальному регістрі - акумуляторі, а для завантаження операндів необхідно було явно вказувати адресу відповідної комірки пам'яті. Таким був набір команд обчислювальної машини Baby (1948), розробленої в Манчестерському університеті, яка вважається першою ЕОМ, в якій достатньо повно був реалізований принцип збереження програми в пам'яті. Цей набір складався з наступних команд (тут А - регістр акумулятора, S - комірка пам'яті, представлена своєю адресою)
[000]JMP S: CI = S [010]LDN S: A = -S [011]SUB S: A = A - S [011]CMP: If A < 0, CI = CI + 1 [100]JMP S: CI = CI+S [110]STO S: S = A [111]HLT: Закінчити програму
Звичайна програма складання двох чисел в акумуляторі в цій архітектурі системи команд виглядала так:
LDN X1; A=-x1 SUB X2; A=A-y=-x-y=-(x+y) STO Y; Y=-(x+y) LDN Y; A=-(-(x+y)=x+y
Майже в той самий час (1948) під Києвом групою інженерів під керівництвом акад. С. О. Лебедєва почались роботи зі створення першої вітчизняної ЕОМ МЕСМ, система команд якої була схожою на наведену вище.
В архітектурі Baby використовувалась, як би ми зараз сказали, відносна адресація безумовних переходів - адреса команди, на яку потрібно було передати керування командою JMP, кодувалась не в самій команді переходу, а зберігалась в комірці запам'ятовуючого пристрою. Це було викликано головним чином необхідністю економії пам'яті (хоча згодом практика програмування показала, що пряма (безпосередня) адресація переходів використовується набагато частіше).
[ред.] Архітектури з індексними регістрами
В наступниці принципів Baby, одній з перших комерційних ЕОМ Ferranti Mark-1 (1952) для цих цілей були вперше застосовані так звані індексні регістри. Можна було налаштувати цю машину так, що перед виконанням команди, інформація одного з таких регістрів сумувалась безпосередньо з самою командою, або деякими її складовими, тобто був реалізований принцип програми, яка самомодифікується в процесі виконання. Таким чином, для організації прямої адресації переходів, достатньо було завантажити в один з індексних регістрів потрібну адресу, залишивши відповідне поле команди JMP нульовим.
[ред.] Архітектури з регістрами загального призначення
Наступним значним вдосконаленням стало введення такого поняття, як регістри загального призначення (РЗП). Вперше вони з'явилися в машині Pegasus (1956) тої ж фірми Ferranti. Кожний з таких РЗП за функціональністю був ідентичний акумулятору перших машин, і це істотно полегшувало процес програмування й прискорювало швидкодію, адже тепер не потрібно було зберігати проміжні результати в повільній пам'яті й увесь час підзавантажувати звідти потрібні змінні. Їх можна було розміщати в регістрах.
Це вдосконалення позначилось й на системі команд. В перших машинах вони були однооперандними (тобто в команді вказувався лише один операнд, а другий завжди знаходився в регістрі-акумуляторі). Тепер же, з появою „безлічі акумуляторів”, одноадресні команди були змінені на двоадресні та триадресні.
[ред.] CISC
З прогресом в області електронних технології й збільшенням швидкодії, стали більше думати й про програміста. В середині 60-х років з'явився клас універсальних машин, разом з ним - поняття про архітектуру. Зворотним наслідком такої турботи стало те, що деякі системи команд того часу нараховували більше десятка способів адресації, не менша кількість регістрів різної функціональності й більше сотні операцій на всі випадки життя, включаючи найекзотичніших, тому згодом такі архітектури системи команд одержали назву повних (complete instruction set computer, CISC). В деяких ЕОМ система команд нагадувала мови високого рівня.
Все це повинно було полегшити й прискорити написання програм і зменшити складність компіляторів, скоротити час налагодження, а також обсяги використовуваної пам'яті, яка тоді коштувала дорого, а чим більше складних дій вдавалося реалізувати в компактних машинних командах (тобто чим вищою була їх семантика), тим менше в пам’яті займала програма.
Однак мало хто утрудняв себе вивченням і використанням всіх цих численних можливостей, тому „повні” системи команд виявлялися вкрай надлишковими.
[ред.] RISC
Але до середини 70-х, зі здешевленням пам'яті й розвитком високорівневих мов такомпіляторів, акценти знову змінились. На машинних мовах переставали писати - ре-зультати роботи оптимізуючих компіляторів стали цілком прийнятними, а писати на мовах високого рівня куди легше й швидше ніж в машинних командах. Стало актуальним питання сумісності та міжплатформеної сумісності програмного забезпечення. До того ж, складні набори команд, реалізовані за допомогою повільних мікропрограм, обмежували можливості для подальшого росту швидкодії за рахунок мікроархітектурних оптимізацій.
Так ера складних наборів команд закінчилася, поступившись місцем новим архітектурам із скороченим набором (reduced instruction set computer, RISC), які створювалися із прицілом на максимальну реалізацію можливостей сучасних компіляторів і заздалегідь проектувалися з урахуванням можливої оптимізації процесу обчислень на рівні мікро-архітектури.
[ред.] VLIW
Однак зараз перед проектувальниками у весь зріст постала нова проблема - складність сучасних процесорів стає просто шаленою. Мікроархітектурні методи динамічного планування, які перевпорядковують команди та виявляють схований паралелізм, дають істотний приріст в продуктивності, але вимагають створення винятково складних апаратних структур, які надто складно проектувати й втілювати. Тому зараз на перший план виходять системи з довгим командним словом (very long instruction word, VLIW), в яких більша частина механізму сполучення операцій виконується на програмному рівні, а процесору дається вже готовий «план дій». Апаратурна структура виходить простіше, що робить такі системи досить перспективними, незважаючи на безліч складностей, пов'язаних з їхнім використанням у цей час.
Рішення, які приймаються на рівні архітектури системи команд, мають істотний вплив на основні характеристики майбутньої ЕОМ, її внутрішню організацію. Тому і спостерігається певний "процесороцентризм" в популярних оглядах сучасних комп'ютерних архітектур, хоча це й не дуже коректно, тому що архітектура ЕОМ включає в себе масу інших складових.
[ред.] Класифкація архітектур системи команд
В залежності від організації взаємодії між обчислювальним пристроєм, регістрами й пам'яттю, виділяють наступні класи архітектур:
[ред.] Стекові архітектури
У стекових архітектурах набір регістрів (або відповідна область пам'яті, де відбувається безпосередня обробка даних) організований у стек (stack) або магазин. Принцип дії цієї структури дійсно нагадує магазин автомата, в якому можна послідовно завантажувати патрони, причому при завантаженні кожного наступного, попередні опускаються на позицію долілиць. Діставати патрони доведеться в зворотному порядку: перший із завантажених буде вийнятий останнім.
Аналогічно, для керування регістровим стеком вводяться дві спеціальні команди: PUSH і POP («заштовхнути» і «виштовхнути»). З їхньою допомогою організується взаємодія з основною пам'яттю: команда PUSH кладе операнд на вершину стека, команда POP вертає значення c вершини та кладе на вершину наступний елемент. В якості поточних операндів в стековій машині завжди маються на увазі дві верхніх позиції стека, тому в обчислювальних командах навіть немає необхідності вказувати адреси операндів (говорять, що система команд стекових машин – нульадресна). Результат операції записується знову в вершину стека на місце першого операнда, а на місце другого піднімається наступний і так до спустошення стека.
Стекові архітектури прості в реалізації, тому багато перших ЕОМ були побудовані саме в такий спосіб. Стековими, до речі, були й перші калькулятори. Однак продуктивність таких архітектур по сьогоднішніх мірках невисока, та й підвищувати її можна хіба що за рахунок зменшення часу циклу. Однак є галузі, де продуктивність - не головний показник, і сьогодні стекові архітектури є досить перспективними для застосування в промислових системах керування та широкому класі вбудованих систем, де важливі простота й дешевина реалізації разом з прийнятною швидкістю обробки. Краще інших пристосовані стекові машини для забезпеченням режиму реального часу реакції на переривання, що має першорядну важливість у системах керування.
[ред.] Акумуляторні архітектури
В акумуляторних архітектурах „уявним” залишається тільки один операнд, що перебуває в спеціальному регістрі акумулятора. Другий операнд береться безпосередньо з пам'яті або з тимчасового сховища, в яке завантажується попередньо. Розвитком цього принципу можна вважати архітектури з наборами спеціалізованих регістрів, в яких деякі регістри були закріплені за певними операціями, або існували якісь інші обмеження на їхнє використання.
Акумуляторні архітектури були досить популярні в перших ЕОМ через свою простоту. Спеціалізовані регістри були популярними в архітектурах 70-х років, зокрема, застосовувалися в IBM S/360 і в мікропроцесорах серії x86, а сьогодні одержали свій розвиток в архітектурах цифрових сигнальних процесорів (digital signal processor, DSP).
[ред.] Архітектури «регістр-пам'ять» і «регістр-регістр»
В командах архітектур типу «регістр-пам'ять» допускається в команді вказувати в якості місцезнаходження одного з операндів комірки пам'яті. В архітектурах «регістр-регістр» завантаження операндів з пам'яті й збереження результатів виконуються спеціальними командами, і безпосередньо в обчисленнях допускається використання тільки операндів, які знаходяться в регістрах процесора. Останній підхід покладений в основу архітектур зі скороченим набором команд (RISC).
Архітектури «регістр-пам'ять» і « регістр-регістр» відносяться до розряду регістрових архітектур. В них як основне сховище операндів використовується набір регістрів загального призначення або спеціалізованих регістрів. Використання регістрів веде до істотного підвищення продуктивності: по-перше регістрова пам'ять швидше оперативної, по-друге набір регістрів дає більше можливостей програмісту й компілятору для організації складних обчислень (на відміну, наприклад, від стекових архітектур, де порядок обчислення визначається однозначно й не може бути змінений), полегшує реалізацію мікроархітектурних методів підвищення продуктивності обчислень, таких як конвеєризація або сполучення операцій.
Розумне планування використання регістрів в процесі обчислень дозволяє скоротити відсоток звертань до повільної оперативної пам'яті за рахунок повторного використання результатів обчислень і зберігання в регістрах часто використовуваних змінних. В зв'язку з останньою обставиною зростає роль архітектур з регістрами загального призначення, де всі регістри мають однакову функціональність, що дає компілятору максимум можливостей щодо оптимального їх розподілу в процесі обчислень. Оптимізувати використання регістрової пам'яті на архітектурах зі спеціалізованими регістрами значно важче через наявні обмеження на використання тих або інших регістрів.
Кількість регістрів в регістрових архітектурах залежить конкретних завдань, адже в одному випадку необхідно оперувати великими масивами даних і постійно довантажувати операнди в регістри, в іншому всі обчислення локалізовані й при наявності достатньої кількості вільних регістрів, можна вмістити там всі використовувані змінні.
[ред.] Архітектури "пам'ять-пам'ять"
Ще один клас архітектур, що залишився без уваги - «пам'ять-пам'ять», де дозволяється робота безпосередньо з оперативною пам'яттю, але він давно зжив себе й зараз знайти втілення цієї архітектури можна хіба що в музеях (як приклад можна привести досить розповсюджену в 70-і роки серію VAX фірми Digital Inc.)
[ред.] Адресність команд
Стекова архітектура може зватися нульадресною або нульоперандною, в ній і вхідні операнди, і адреса для запису результата визначені за замовчуванням, тому в команді нічого вказувати не потрібно.
Акумуляторні архітектури є однооперандними.
Архітектури типу регістр-пам'ять часто мають двооперандний формат – в команді вказується місценаходження обох джерел операції, а результат за замовчуванням записується на місце першого, яке при необхідності повторного використання доведеться заново завантажувати.
Архітектури «регістр-регістр» мають найбільш гнучкий триоперандний формат з явною вказівкою як операндів-джерел, так і регістра, в якому буде збережений результат. В модулях векторної обробки (наприклад, обробки мультимедійних даних) сучасних процесорів загального призначення та процесорах цифрової обробки сигналів можна знайти й спеціалізовані чотириоперандні команди.
[ред.] Класифікація команд
Всю номенклатуру операцій, реалізованих в сучасних ЕОМ, можна розбити на наступні функціональні групи:
- арифметичні й логічні – для цілочисельних арифметичних і логічних обчислень (додавання, віднімання, множення, зсуви й логічні операції, порівняння тощо)
- пересилання даних – команди завантаження/збереження в RISC-процесорах, команди переміщення даних (типу mov) в архітектурах, що допускають пряму роботу з пам'яттю
- управління – для умовної або безумовної зміни ходу виконання програми, обробки виняткових ситуацій
- системної або привілейовані – команди управління віртуальною пам'яттю, переключенням контексту, привілейовані команди операційної системи
- арифметичні з плаваючю комою – для арифметичних операції із числами у форматі плаваючої коми
- команди десяткової арифметики
- робота з рядками (strings) – пошук в рядку, пересилання рядка, порівняння рядків
- графічні – векторні операції, що прискорюють обробку графічних сцен
