|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Рівень архітектури команд
У цьому розділі детально обговорюється рівень архітектури команд. Він розташований між мікроархітектурним рівнем і рівнем операційної системи, як показано на мал. 8.1. Історично цей рівень розвинувся перш за всіх решти рівнів і спочатку був єдиним. В наші дні цей рівень дуже часто називають «архітектурою» машини, а іноді (що неправильне) «мовою асемблера». Рівень архітектури команд має особливе значення: він є зв'язуючою ланкою між програмним і апаратним забезпеченням. Звичайно, можна б було зробити так, щоб апаратне забезпечення відразу безпосередньо виконувало програми, написані на C, С++, FORTRAN 90 або інших мовах високого рівня, але це не дуже хороша ідея. Перевага компіляції перед інтерпретацією була б тоді втрачена. Крім того, з чисто практичних міркувань комп'ютери повинні уміти виконувати програми, написані на різних мовах, а не тільки на одній. По суті, всі розробники вважають, що потрібно транслювати програми, написані на різних мовах високого рівня, в загальну проміжну форму — на рівень архітектури команд — і відповідно конструювати апаратне забезпечення, яке може безпосередньо виконувати програми цього рівня (рівня архітектури команд). Рівень архітектури команд зв'язує компілятори і апаратне забезпечення. Це мова, яка зрозуміла і компіляторам, і апаратному забезпеченню. На мал. 8.1 показаний взаємозв'язок компіляторів, рівня архітектури команд і апаратного забезпечення. У ідеалі при створенні нової машини розробники архітектури команд повинні консультуватися і з укладачами компіляторів, і з тими, хто конструює апаратне забезпечення, щоб з'ясувати, якими особливостями повинен володіти рівень команд. Якщо укладачі компілятора вимагають наявності якоїсь особливості, яку інженери не можуть реалізувати, то така ідея не пройде. Так само, якщо розробники апаратного забезпечення хочуть ввести вкомп'ютер яку-небудь нову особливість, але укладачі програмного забезпечення не знають, як побудувати програму, щоб використовувати цю особливість, то такий проект не буде ніколи втілений. Після довгих обговорень і моделювання з'явиться рівень команд, оптимізований для потрібних мов програмування, який і буде реалізований. Але все це в теорії. А зараз перейдемо до суворої реальності. Коли з'являється нова машина, перше питання, яке задають всі потенційні покупці: «Чи сумісна машина з попередніми версіями?». Друге питання: «Чи можу я запустити на ній мою стару операційну систему?» І третє питання: «Чи працюватимуть мої прикладні програми на цій машині і чи не буде потрібно їх змінювати?» Якщо яке-небудь з цих питань одержує відповідь «немає», розробники повинні будуть пояснити, чому. Покупці рідко рвуться викинути все старе програмне забезпечення і почати все наново.
Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.002 сек.) |