Починаючи від перших поколінь ЕОМ, стало зрозумілим, що архітектура комп'ютерів иерархична, і в ній можна виділити декілька рівнів. З роками ці рівні тільки нарощувалися і розросталися із-за об'єму нових засобів і технологій, що постійно збільшується.
У різних джерелах дається різне число рівнів архітектури. Укрупнивши їх, можна виділити наступні:
ПРИЗНАЧЕНИЙ ДЛЯ КОРИСТУВАЧА.
До нього відносяться всі апаратні і програмні засоби, що знаходяться поза комп'ютером, – різноманітні співпроцесори попередньої обробки даних, прикладні програми і інші засоби попередньої обробки інформації до безпосереднього оброблювального пристрою.
ЗАСОБИ ПЕРЕДАЧІ ІНФОРМАЦІЇ всередину комп'ютера.
Це - зовнішні шини, контроллери цих шин, відповідні інтерфейси, засоби введення-виводу, контроллери, які управляють цими процесами, а також певна частина ОС.
ПРОЦЕСОРНИЙ.
До цього рівня відносять основні складові власне комп'ютера, а саме: процесор, пам'ять, системна шина, ОС і її ядро.
РЕГІСТРОВИЙ.
Фактично, це вміст внутрішньої центральної частини, а саме: внутрішні шини процесора, засоби внутрішньої передачі інформації, різні конвеєри, внутрішня архітектура пам'яті, регістри, а також та частина ОС, яка “відповідальна” за це.
ЛОГІЧНИЙ.
Тут мова йде про з'єднання структурних елементів між собою і про їх логічну організацію. Іншими словами – це схемний, мікропрограмний рівень.
Завдання архітектора – здійснити вибір оптимального рішення, що задовольняє всім рівням, адже конкуренція в цій області дуже і дуже велика.
Семантичний розрив.
Ми відзначили один з головних недоліків архітектури фон Неймана – великий об'єм програмного забезпечення із-за тривіального рівня машинної мови.
Неодноразово робилися спроби мінімізувати кількість необхідних тривіальних команд. Але від деяких команд, наприклад таких, як команда СТОП (END), ніяк не можна було відмовитися. До того ж це не завжди необхідно, адже іноді потрібні машини послідовні, а іноді - паралельні.
Так от чи можна підняти рівень машинної мови? Простіше кажучи, чи можна мову високого рівня зробити машинною?
Групами фахівців в СРСР і в провідних країнах світу велися розробки таких машин, внутрішньою мовою яких була б мова високого рівня.
Але всі у результаті приходили до одного і тому ж висновку: так конструювати машину недоцільно. Так, вигідно. Але недоцільно.
Довго шукали відповідь, чому ж так відбувається.
І, нарешті, Г. Майерс знайшов причину:
семантичний розрив – це відмінність між принципами, якими керуються, з одного боку, розробники архітектури ЕОМ (hardware), а з іншої – розробники ПО, в першу чергу, мов високого рівня.
Іншими словами, для інженера зрозумілою мовою є схеми, адже будь-який інженер-розробник керується якимись структурними елементами (суматорами, лічильниками і тому подібне), сполучає їх якимсь чином і примушує взаємодіяти. А ось автори мов високого рівня піклуються, в першу чергу, про полегшення роботи програмістів і, створюючи чергового “високого” оператора не піклуються далі про те, що за цим оператором стоятиме, які структурні елементи його реалізують.
Розробники Hardware і Software мають різні цілі і по разному підходять до рішення задачі підвищення продуктивності і надійності.
У цьому і полягає недоцільність таких сумісних розробок.
Тепер проілюструємо семантичний розрив.
Наприклад, візьмемо алгоритм Хаффмана і застосуємо його для зменшення об'єму пам'яті програми.
Допустимо, є декілька команд (сім) і у них різна вірогідність появи.
A
B
C
D
E
F
G
0.5
0.3
0.1
0.03
0.03
0.02
0.02
Хаффман запропонував:
Чим менше вірогідність появи команди, тим більше може бути її довжина.
Тобто, мінімізуватимемо довжину і прагнутимемо до оптимуму, який обчислюється як ентропія:
H= -p E log (pi)
Виходить, що на 1000 команд ми матимемо загальну довжину в 1888 битий.
Але якщо використовувати три бита на команду, то для 1000 команд буде потрібно 3000 битий – це не мінімум. Потрібно якось зменшити цю кількість.
0.5
0.5 1
0.3 0.5
0.3
0.2
0.1
0.1 0.1
0.03 0.06
0.04
0.02
Примітка: кількість кружечків в дорозі відповідає кількості бітів.
Таким чином, маємо:
0.5 • 1 + 0.3 • 2 + 0.1 • 3 + 0.1 • 5 = 1.9
Тобто “середня” команда матиме довжину 1.9 битий.
На 1000 команд буде потрібно 1900 битий – це майже мінімум.
Але виникає питання, як визначити кінець команди? Адже якщо ми маємо сім команд, то щоб їх розмежувати в пам'яті, потрібно ставити деяку ознаку закінчення кожної команди. Тоді вже код команди складатиметься з як мінімум п'яти битий.
А зараз уявимо, що це потрібно реалізувати за допомогою комбінаційної схеми. Як відомо, КС сама по собі характеризується великими затримками, а якщо тепер це буде КС від п'яти змінних, то можна уявити – яка буде її складність!
Крім того, виникає ще одна проблема: які повинні бути регістри? Виходить, що, враховуючи максимальну по довжині команду регістри теж повинні бути цієї максимальної довжини.
Приходимо до висновку: таку “оптимізацію” проводити недоцільно