Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Рівні архітектури. Проблема семантичного розриву



 

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

У різних джерелах дається різне число рівнів архітектури. Укрупнивши їх, можна виділити наступні:

 

  1. ПРИЗНАЧЕНИЙ ДЛЯ КОРИСТУВАЧА.

До нього відносяться всі апаратні і програмні засоби, що знаходяться поза комп'ютером, – різноманітні співпроцесори попередньої обробки даних, прикладні програми і інші засоби попередньої обробки інформації до безпосереднього оброблювального пристрою.

 

  1. ЗАСОБИ ПЕРЕДАЧІ ІНФОРМАЦІЇ всередину комп'ютера.

Це - зовнішні шини, контроллери цих шин, відповідні інтерфейси, засоби введення-виводу, контроллери, які управляють цими процесами, а також певна частина ОС.

 

  1. ПРОЦЕСОРНИЙ.

До цього рівня відносять основні складові власне комп'ютера, а саме: процесор, пам'ять, системна шина, ОС і її ядро.

 

  1. РЕГІСТРОВИЙ.

Фактично, це вміст внутрішньої центральної частини, а саме: внутрішні шини процесора, засоби внутрішньої передачі інформації, різні конвеєри, внутрішня архітектура пам'яті, регістри, а також та частина ОС, яка “відповідальна” за це.

 

  1. ЛОГІЧНИЙ.

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

 

Завдання архітектора – здійснити вибір оптимального рішення, що задовольняє всім рівням, адже конкуренція в цій області дуже і дуже велика.

Семантичний розрив.

 

Ми відзначили один з головних недоліків архітектури фон Неймана – великий об'єм програмного забезпечення із-за тривіального рівня машинної мови.

Неодноразово робилися спроби мінімізувати кількість необхідних тривіальних команд. Але від деяких команд, наприклад таких, як команда СТОП (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 битий – це майже мінімум.

 

Але виникає питання, як визначити кінець команди? Адже якщо ми маємо сім команд, то щоб їх розмежувати в пам'яті, потрібно ставити деяку ознаку закінчення кожної команди. Тоді вже код команди складатиметься з як мінімум п'яти битий.

А зараз уявимо, що це потрібно реалізувати за допомогою комбінаційної схеми. Як відомо, КС сама по собі характеризується великими затримками, а якщо тепер це буде КС від п'яти змінних, то можна уявити – яка буде її складність!

Крім того, виникає ще одна проблема: які повинні бути регістри? Виходить, що, враховуючи максимальну по довжині команду регістри теж повинні бути цієї максимальної довжини.

Приходимо до висновку: таку “оптимізацію” проводити недоцільно

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.