Введення в двійкові технології

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

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

1. Розрядність
Отже, кругом одні біти, і з ними треба щось робити. Що з ними потрібно зробити в першу чергу? Мабуть, упакувати в мінімальну одиницю пам'яті. Від пам'яті в ІТ нікуди не дінешся, зрозуміло що вона повинна бути структурована, і що найпростіший спосіб це зробити — представити її у вигляді лінійної послідовності осередків однакової розрядності. Якщо пам'ять визначає просторовий (статичний аспект інформаційної системи, тимчасового (динамічному) слід зіставити процес, який незалежно від цільових завдань можна було б представити у вигляді сукупності дій по відновленню пам'яті. Таким чином маємо пам'ять і керуючі нею пристрої, які визначають динаміку інформаційного процесу, з прилеглою інформаційною структурою, яка визначає спосіб взаємодії пристроїв з пам'яттю та між собою. Досить багата архітектура передбачає ієрархічну структуру управління, і при всьому потенційного різноманітті її функціональних пристроїв на перших кроках розгортки двійкових технологій виникає потреба у визначенні такого керуючого пристрою, яке було б здатне забезпечити функціонування всієї системи за допомогою формальної мови — одним словом необхідний процесор. Вміру багаті інформаційні системи можуть управлятися одним процесором, хоча такий варіант вирішення навряд чи можна вважати типовим, оскільки «поділ праці» в інформаційних процесах завжди вітається. Ну і з підвищенням складності задач це число може бути збільшене від одного до, скажімо, мильена процесорів (розподілені обчислення), що утворюють власну ієрархію управління. Максимум — «почтальена», адже якщо складність модельованого процесу перевищує можливості цього «почтальена» (скажімо — за секунду потрібно перелопатити все дерево варіантів у шахах), то для вирішення завдань такого рівня вже знадобляться квантові технології з використанням кубітів, що дозволяють здійснити зниження геометричній прогресії в обчисленнях до арифметичній. Таким чином можна визначити горизонти доцільності застосування двійкових технологій.

Існує два принципових способи інтерпретації зберігаються в пам'яті даних: власне дані і код, виконуваний арифметико-логічним пристроєм (АЛУ), що задає безліч елементарних способів маніпулювання даними, складових формалізований мову низького рівня, який виступає в ролі посередника між «залізом» і абстрактною моделлю інформаційного процесу. Усі дії по управлінню системою можна розділити на внутрішні, що здійснюють взаємодію регістрів процесора між собою і з адресної їм безпосередньо пам'яттю, і зовнішні, що реалізують «обмін речовин» між функціональним ядром і «навколишнім середовищем» за допомогою прямих і зворотних зв'язків. Таким чином, однією з найбільш пріоритетних завдань при проектуванні інформаційних систем є створення машинної мови (асемблера), що визначає безліч атомарних дій, що забезпечують зберігання, обмін та перетворення даних. Зрозуміло, що пристрій, який всім цим займається, повинно бути логічним і неабиякою мірою арифметичним — звідси абревіатура АЛУ.

На даному етапі маємо неопределимое безліч способів поєднання машинної мови з принципами комунікації між пристроями. Перший крок формалізації полягає у визначенні правил, справедливих для будь-якої функціональної системи, що поєднує централізоване управління інформаційними потоками за допомогою машинної мови з лінійною і моноширной організацією пам'яті. Історично склалося так, що поняття «розряди» втратила свою актуальність у зв'язку з бурхливим розвитком ІТ за законом Мура, з-за якого (закону, а не Мура) доводилося робити все поспіхом а потім затикати дірки і плодити купу баластної інформації, необхідної для вирішення проблем сумісності. Щоб уникнути розбіжностей принаймні на базовому рівні організації інформаційних систем доцільно постулювати розрядність фундаментальною константою, припускаючи при цьому, що втрачені можливості, доступні при вільному з нею зверненні, будуть несуттєвими в порівнянні з тим перевагою, що дає можливість моноразрядного способу квантування.

2. Сторінка пам'яті
Отже, наступним елементом у списку дефініцій після біта (пам'ять, процесор і пристрої вважаємо само собою зрозумілими) вважаємо розрядність. Відзначивши галочкою опцію «моноразрядность», пройдемося по інших глобальних налаштувань і подивимося, які значення там стоять за замовчуванням.

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

R — розрядність (ширина одиниці пам'яті в бітах)

A — кількість адресованих одиниць пам'яті (обсяг адресного простору)

C — кількість машинних інструкцій (обсяг командного простору)

Задаємо ключова умова, що сприяє цілісності й завершеності архітектури, в основу якої покладено принцип моноразрядности:

A = C = 2 ^ R

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

Чи існують інші умови, що задовольняють перерахованим вище критеріям і очевидні без поглиблення в деталі розробки низькорівневої архітектури? Так, принаймні одне таке умова:

R = 2 ^ N

Дотримання цієї умови означає, що для завдання номери будь-якого біта в комірці потрібно ціле число біт (знову ж, надлишок або недолік тут небажаний з міркувань зручності написання і надійності роботи машинного коду).

Очевидно, що N=4 — це мінімальне прийнятне значення, оскільки 256 байт пам'яті при N=3 годиться хіба що для програмування ялинкових гірлянд. При N=5 отримуємо обсяг пам'яті, що відповідає останнім досягненням у сфері ІТ. Але якщо вважати головним призначенням пам'яті, адресної процесором, зберігання машинного коду (двигуна), а більшу частину даних, якими маніпулює цей движок, винести за межі адресуемого простору (і як наслідок — припускати їх носіями зовнішні пристрої), то при такому обсязі пам'яті (16 Гб) машинний код буде складати лише незначну її частину, а все інше простір будуть займати дані. У мегабите ж машинного коду при N=4, написаного на ефективному асемблере, за умови винесення даних за межі адресного простору можна буде розмістити, мабуть, ядро повноцінної операційної системи. Так що в принципі моношестнадцатиразрядная архітектура здатна забезпечити необхідний мінімум ресурсів, а саме: 65536 слів адресної пам'яті і стільки ж машинних команд, складових повний список елементарних дій, виконуваних процесором.

Обмеження досить суттєве і створює ряд незручностей, викликаних насамперед невеликим об'ємом адресної пам'яті, вимагає винесення оброблюваних даних за межі адресного простору. Зручно адже, коли вони «лежать під рукою» — тобто доступні процесору безпосередньо, а не розташовані «десь там», у зовнішній пам'яті, звідки їх необхідно пересилати у внутрішню, що з ними робити, після чого відсилати назад. Це момент є, мабуть, самим вузьким місцем моношестнадцатиразрядной архітектури і загрожує ускладненням мови високого рівня, оскільки написані на ній програми не зможуть абстрагуватися від нюансів, пов'язаних з організацією обміну даними з зовнішніми пристроями. Правильна розстановка акцентів дозволяє вирішити всі ці проблеми, ну і взагалі при написанні програми програмісту було б не зайвим уявляти собі динаміку інформаційного процесу в повному обсязі, а не на рівні абстрактних абстракцій. Також можна відзначити, що ідеологія програмування в такому разі змістить акценти в бік створення цілісних і завершених рішень, які містяться в одну сторінку пам'яті розміром у мегабіт — а це чималий обсяг для забезпечення досить складною функціональності. Принципові способи вирішення проблем, що виникають при урізуванні обсягу адресної пам'яті до 64-х килослов, будуть розглянуті пізніше, тут я б хотів акцентувати увагу на перевагах від прийняття N=4 в якості фундаментальної константи.

Насамперед це стосується командного простору (КП): 16 біт цілком вистачає, щоб реалізувати АЛУ в його класичному вигляді. Так, збільшення розрядності сучасних процесорів до 32, а згодом — до 64, практично не позначилося на їх системі машинних команд і по суті асемблер залишився 16-розрядним. В принципі, нічого не заважає придумати машинний мова, система команд якого буде ефективно використовувати 32 і більше біт, але як показує практика, гострої необхідності в цьому не виникає, тому тут доцільно прийняти 16-розрядний обсяг КП як значення за замовчуванням. До того ж N=4 забезпечує додаткову зручність, а саме:

R % N = 0

Дотримання цієї умови означає, що в одній комірці пам'яті можна розмістити ціле число значень в діапазоні [ 0… R ) (наприклад, для N=5 ця умова не дотримується, оскільки в даному випадку R дорівнює 32-м бітам, не ділиться на 5 без залишку). Оскільки розрядність є фундаментальним параметром, таку властивість дозволить забезпечити в подальшому додаткові переваги, хоча в порівнянні з попередніми аргументами цей — третього порядку значущості.

3. Зовнішнє ОЗП
Отже, прийняття числа 16 в якості фундаментальної константи визначає базову сумісність просторового та часового аспектів інформаційного процесу, а саме: сторінки пам'яті об'ємом 64 килослова і перелік атомарних дій того ж обсягу і формату. Звідси поняття розрядності, що забезпечує цей загальний обсяг і формат — мегабіт «каші» з нулів і одиниць, первинно структурований квантами по 16 біт, складових слово даних. Як наслідок — одна комірка пам'яті здатна вмістити адресу будь-якої іншої клітинки або містить вичерпну інформацію про виконуваному на даний момент дії. Передбачається, що незалежно від деталей реалізації системної архітектури, розрядність забезпечує сумісність її функціональних складових на першому рівні абстрагування від фіз. процесів, сприяючи тим самим зручності формалізації цієї архітектури. При цьому упущення потенційних можливостей від прийняття такого обмеження передбачається несуттєвим — тобто далі я виходжу з припущення про те, що якщо раціонально розпорядитися цими початковими ресурсами, то можна буде створити на їх базі ефективну інформаційну модель, скажімо, будь-якої складності в межах «почтальена». Мегабіт даних є адже не верхнім обмежувачем обсягу інформаційних ресурсів, а черговий (конкретно — третьої після біта і слова) ступенем формалізації. Ускладнення модельованих процесів природним чином веде до ієрархічної структури управління, і вважаючи розрядність актуальною і для наступних ступенів їх організації, отримуємо величину обсягу зовнішнього ОЗП, зручну своєю сумісністю з шестнадцатиразрядной архітектурою: 65536 * 65536 сторінок пам'яті = 8 ГБ. Перекладаю на загальноприйняті байти, і як можна переконатися ця цифра знаходиться в хорошому відповідності з поточними вимогами до ресурсоємності технологій. Принципова відмінність полягає в тому, що спільна пам'ять не може бути адресована процесором безпосередньо або ж доведеться використати для цього два слова пам'яті. Останнє саме по собі не проблема, однак у зв'язку з тим що становлять систему пристрої і процесори мають між собою цю пам'ять якось поділити, виникає безліч нюансів по її розподілу і забезпечення до них доступу. Вважаючи спочатку довільним спосіб, яким це можна зробити, спробую все ж виділити ключові моменти, які з необхідністю повинна враховувати формалізована модель інформаційного процесу, побудована на філософії моноразрядности.

4. Інтегрована система
До цього моменту адресується пам'ять передбачалася орієнтованої на зберігання машинного коду, хоча це і не виключало можливості зберігання у ній даних. Але так не вийде обробити безпосередньо сторінку пам'яті цілком, адже хоч якусь її частину повинна займати сама програма обробки. Оскільки передбачається прийняття сторінки в якості стандартної одиниці фрагментації даних, виникає необхідність цю проблему вирішити. Найпростіше це зробити шляхом включення в зону видимості процесора додаткової сторінки, яка могла б слугувати буфером, здійснюють обмін даних з зовнішньою пам'яттю, не зачіпаючи сторінку машинного коду (при цьому два біта статусу доведеться відвести під визначення джерела і приймача відповідно, щоб дані можна було ганяти як в межах однієї з двох сторінок пам'яті, так і між ними). Через невеликого обсягу сторінки технологічно не складе праці забезпечити пересилання даних одним кадром, не дроблячи цей мегабіт на кванти по одному слову, що дозволить звести на «ні» тимчасові витрати на фрагментацію великих обсягів зовнішніх даних, призначених для обробки процесором. Можна також обійтися без того, щоб ганяти дані туди-сюди, використовуючи технологію підстановки, що дозволяє вибрати будь-яку з 65536 сторінок зовнішнього ОЗП і адресувати її процесором безпосередньо. Якщо те ж саме зробити зі сторінкою коду, то можна буде виконувати зберігаються у зовнішній пам'яті програми, знімаючи таким чином обмеження на їх розмір до 64 килослова і розширюючи його до 4-х гигаслов.

Спираючись на критерій допустимості підстановки сторінки коду/даних з зовнішнього ОЗП в адресуемую процесором область, доцільно розділити процесори на ведучі і ведені. З одного боку це поділ умовно, оскільки ієрархія управління може бути структурована як завгодно; з іншого боку, є сенс виділити один або декілька процесорів, що складають верхній рівень управління системою і здатних її конфігурувати — таких як ядро операційної системи, диспетчер зовнішньої пам'яті, аналог BIOS та інших, орієнтованих на приватне зберігання виконуваного коду і в яких всі ці підстановки даних (а особливо невідомого коду з зовнішнього ОЗП) з міркувань надійності використовувати було б небажано. Власне, на те й розраховано число 16, щоб природним чином забезпечити первинну розмітку інформаційних ресурсів згідно з вимогами до швидкодії та ступеня автономності процесів, цими ресурсами оперують. Тут все досить тривіально: виходячи з уявлення про те, що в основу маніпулювання даними покладено двійковий код, беремо двійку і записуємо її фундаментальні послідовності:

— n ^ 2 | 2 ^ n

— | 2 ^ 0 = 1

2 * 2 = 4 | 2 ^ 1 = 2

4 * 4 = 16 | 2 ^ 2 = 4

16 * 16 = 256 | 2 ^ 4 = 16

256 * 256 = 65536 | 2 ^ 16 = 65536

— Як видно, що число 16 — величина не тільки мінімально допустима, але ще й «сама кругла» серед довколишніх — тобто не вдаючись у деталі реалізації інформаційної моделі можна констатувати зручність фасування інформації порціями саме такої ємності (вищезгадана умова «R % N = 0», соблюдающееся для наступного за списком величини розрядності, рівній аж 256). З наведених раніше міркувань можна також переконатися в тому, що первинна розгортка принципу моношестнадцатиразрядности на ієрархію управління добре узгоджується з практичним застосуванням, адже інформаційні процеси в залежності від ступеня автономності розглянутого елемента системи диференціюються згідно з критерієм швидкодії, обернено пропорційного інформаційної ємності процесу — з чого випливає поняття «кешу», розписаного за рівнями організації системи: «кеш першого рівня», «кеш другого рівня», і вся ця ієрархія зазвичай укладається в декілька поверхів. При R=16 маємо наступні показники:

кеш 0-го рівня (слово шириною в 16 біт): R-егистры процесора, призначені для адресації внутрішньої пам'яті (швидше за все вони будуть обмінюватися даними між собою у вигляді відсутності необхідності виходити за рамки фізичної локалізації АЛУ)
кеш 1-го рівня (блок пам'яті об'ємом до 64 килослова = 1 мегабіт): сторінки внутрішньої пам'яті, призначені для безпосередньої адресації процесором (одна або дві — у більшому їх числі при наявності можливості повного оновлення сторінки за кілька процесорних тактів необхідності не виникає). Закріплю за цим типом пам'яті абревіатуру АЗУ — тобто адресується.
кеш 2-го рівня (зовнішнє ОЗП ємністю 64 килостраницы = 64 мегабіт): пам'ять, використовувана спільно пристроями, складовими інтегровану систему — автономну одиницю, завершену модель інформаційного процесу, здатну взаємодіяти з іншими системами на загальних підставах (з точки зору системи мережева карта, яка забезпечує можливість міжсистемної взаємодії — лише один з пристроїв, функціонування якого може бути описано тими ж виразними засобами, що призначені для відображення процесів обміну даними всередині автономно функціонуючої системи).
кеш 3-го рівня (ПЗУ ємністю до 64 килоОЗУ = 4 петабита): на жорсткий диск такого розміру помістяться, наприклад, всі зняті в світі фільми, так що інформаційну ємність цього рівня можна вважати необмеженою. Також можна вважати неактуальним чергове множення на 65536, задає наступний константный показник інформаційної ємності. Власне, і від цього немає особливого сенсу, оскільки оперування настільки великими обсягами даних розмиває уявлення про те, для чого вони можуть бути призначені і як вони можуть бути структуровані. Крім того, ця пам'ять дуже повільна, щоб можна було вважати її «кешем» — так що на відміну від попередніх рівнів її немає сенсу жорстко лімітувати. 4 гигаслова ОЗП передбачаються достатніми для того, щоб не виникало потреби занадто часто ганяти дані в ПЗП і назад. Якщо ж обчислення виявляться більш ресурсоємними, то природно було б вирішити цю проблему шляхом залучення достатнього числа процесорів і ефективного розподілу між ними функціонального навантаження.

Так на основі розрядності рекурсивным методом утворюються 3 рівня абстракції, які визначають структурну глибину вкладеності процесів, пойменованих перечислимым безліччю мовних конструкцій, що визначають формат і граничні умови застосовності зіставлених ним дій:

0 => 1: система машинних команд, вичерпно визначає первинний спосіб квантування дій
1 => 2: мова програмування високого рівня (передбачається природної його об'єктно-орієнтована спрямованість, і як наслідок — специализированность зовнішнього ОЗП на зберіганні об'єктів)
2 => 3: мова системних запитів (макросів) — наприклад командна або адресна рядок, що дозволяє виконувати складні послідовності дій однією командою з безліччю передбачених для неї параметрів. По суті цей рівень можна вважати сферою формалізації ключових функцій операційної системи.
3 => 0: спочатку передбачається умовним у вигляді умовної невичерпність ресурсів, що входять до його складу. Виходячи з уявлення про те, що одним точковим дією «по кліку миші» можна задіяти інформаційний процес будь-якої інформаційної ємності і складності, вважаємо що сюди можна віднести будь-які зазначені дії, що не ввійшли в три попередніх категорії мовних абстракцій. Наділити цей рівень конкретикою дозволяє його замикання на рівень «заліза» — про що подальші міркування.

За змістом формальний мову наступного рівня (якщо вважати його нульовим, а четвертим) передбачає вихід за межі автономної системи, і, як наслідок, повинен бути призначений для іменування дій, що організують межсистемное взаємодія. Але як вже було сказано, межсистемний обмін даними утворює власну ієрархічну структуру — починаючи з низькорівневих протоколів оцифровки аналогових сигналів, через простий та універсальний протокол TCP-IP, на якому тримається робота всесвітньої павутини, ну і так далі — по мірі розширення горизонтів застосовності універсалізація програмних реалізацій стає все більш скрутною. Тут просто слід відзначити, що формалізація мережевих повідомлень має свою специфіку і як наслідок власну термінологічну структуру — починаючи з простих алгоритмів з оцифрування безперервних сигналів з подальшим поетапним приведенням цій «каші з бітів» до виду, «їстівного» для «споживають» її програм, які самі вибудовуються в ієрархію по мірі ускладнення принципів організації обміну даними від низького рівня до високого. Тобто вся ця інформація — вона повинна йти паралельно з розвитком мов формалізації, при цьому не надаючи на них істотного впливу і будучи по суті лише однією з невизначеного безлічі категорій завдань, за допомогою цих мов вирішуваних. А оскільки всі ці питання повинні вирішуватися на рівні операційної системи, то і способи їх формального відображення слід якось розподілити на перших трьох рівнях системної організації. Наприклад, сам TCP-IP пишеться на asm-e, програма перетворення даних посилок в об'єкти — на C++, підтримка адресного рядка оформляється у вигляді макросу ОС, ну а макрос — поняття досить невизначене в плані функціональності і ємності дій, що оперують об'єктами, вже сконструйованими в ОЗП об'єктно-орієнтованими засобами. Він може містити вкладені макроси, що виконують кожен окремо досить складні дії — так що при подальшому поглибленні вкладеності не виникає приводу для запровадження принципово нової інформації.

Черговий рівень абстрагування від конкретики (тобто фізичних процесів, локалізованих в «залозі») повинен ще на порядок підвищити виразну потужність понятійної бази — тобто цей перехід повинен бути якісним, а не кількісно збільшує ресурсомісткість зіставлених йому абстракцій. Перерахованим умовам задовольняє можливість автоматизації конструювання архітектури довільної складності на фізичному рівні на підставі інформаційної моделі, вичерпно описаної формальним мовою. Тобто малюємо в редакторі схему комунікацій, визначаємо роз'єми вводу-виводу для підключення зовнішніх пристроїв, вибираємо прошивки для одного або декількох процесорів, які становлять функціональне ядро системи, тиснемо велику кнопку «створити», після чого пристрій, з яким працює ця програма (на даний момент гіпотетичне), не гірше ніж принтер електронні документи друкує електронні плати, упаковані в коробку, всередині якої реалізована необхідна архітектура. Підключаємо зовнішні пристрої, натискаємо «пуск», і все працює — природно за умови коректності написання та придатності для спільної роботи движків, «зашитих» в програмну пам'ять керуючих процесорів. Класична реалізація припускає варіант з одним процесором, який в числі інших системних утиліт крутить програму, здатну завантажувати інші движки ядра. Ті у свою чергу можуть використовувати що залишилися в наявності процесори, якщо такі передбачені в системі, згідно з цільовим завданням — будь то робота з конкретними пристроями, реалізація багатозадачності або організація розподілених обчислень. В принципі, допустимо варіант з одним процесором, на якому тримається вся система, хоча такий спосіб загрожує серйозним навантаженням на швидкодію.

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

5. Арифметичний і геометричний аспекти інформаційного процесу
Тут я підведу підсумки.

Отже, розрядність R=16, зафіксована в якості фундаментального параметра інформаційної системи, що поєднує просторовий (АЗП) і тимчасової (КП) аспекти інформаційного процесу, забезпечуючи тим самим базову сумісність функціональних пристроїв, і як наслідок — спрощуючи побудова формалізованої моделі різних процесів. Володіючи такими початковими ресурсами, рекурсивным методом послідовно визначаються три рівня системної організації (виділені в списках жирним), передбачають відображення на ієрархію мовних засобів відповідної виразною потужності. З метою адаптації інженерної термінології { двійковий розряд => комірка => АЗУ => ОЗП => ПЗУ } до лінгвістичної пропоную для асоціювання наступну послідовність: { буква => слово => сторінка => тому => бібліотека }

Останній рівень абстракції, замикає ієрархію управління на нульовий (тобто знову ж таки на фіз. процеси, тільки зі зворотного боку), виноситься за рамки списку, оскільки розгляд його елементів має сенс лише при наявності готової архітектури, на якій вони могли би вибудовуватися — в той час як на рівні проектування цю архітектуру лише потрібно матеріалізувати. З урахуванням наведених вище міркувань, цей спосіб полягає у визначенні схеми комунікацій і виборі прошивок керуючих процесорів. Звідси два принципових об'єкта формалізації, перший з яких представлений інформаційними каналами для обміну даними і зав'язаними в них комунікаційними вузлами, а другий — машинним кодом, квантованим елементарними діями перетворення даних. Перший аспект можна назвати «геометричним», оскільки його формальне відображення зручно представляти графічно — у вигляді схем зі стрілками, що вказують напрямок циркуляції інформаційних потоків в системі, а також прямоугольничками та іншими умовними позначеннями її функціональних складових. Другий, відповідно — «арифметичним», оскільки система команд процесора орієнтована на реалізацію базових математичних обчислень. Також можна виділити критерій, на підставі якого визначається принципова різниця в їх функціональному призначенні: якщо «геометричні» абстракції визначають способи організації пересилання даних між пристроями, то «математичні» — способи їх перетворення. При цьому обидва аспекти мають бути відображені в системі команд, тобто C = G U A, C — командне простір загальним обсягом 65536 машинних інструкцій, G — безліч інструкцій, що ініціюють зовнішні механізми обміну даними, A — команди внутрішньої адресації через регістри. Оскільки інструкції, складові безліч G, абстрагуються від перетворення даних і по суті зводяться до команди MOV source --> destination, їх формальне визначення зводиться до ідентифікації джерела і приймача. Але якщо для безлічі A всі способи їх ідентифікації завідомо у нього включені, то команди з безлічі G, що задіють процеси щодо «обміну речовин з навколишнім середовищем», не можуть свідомо «знати», звідки і куди їм доведеться перекидати дані, оскільки схема комунікацій не відображена у складі АЛУ. Щоб така можливість була доступною, цю схему доведеться вважати фіксованою на рівні проектування системи, що позбавить процес проектування гнучкості, а подальший розгляд цього питання сенсу. Якщо ж функціональність команд з групи G думати наперед невизначеної, і з урахуванням того що суть їх дії завжди зводиться до перегонці даних від певного джерела до нікому приймача, то навантаженням на командне простір для безлічі G можна знехтувати і звести його до одного елемента — єдиній команді без параметрів (назву її банально CMD). При цьому інформацію про те, що саме і куди саме слід пересилати, можна буде черпати з регістрів, що посилаються на довільні ділянки АЗУ і ОЗП — так що тут немає принципових обмежень на обсяг і спосіб структурування цільових даних, якими маніпулює CMD. У запропонованому випадку інформація про цьому способі перекладається на апаратну реалізацію тієї частини процесора, яка відповідає за зовнішні комунікації і як наслідок — є складовою частиною їх схеми. Тепер КП майже цілком належить множині A, а завдання формального визначення системи машинних інструкцій і принципів організації управління даними нічого тепер не заважає вирішувати незалежно один від одного.

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

6. АЛУ

Геометричний аспект залишаю поки в стороні, припускаючи що і для нього можна визначити необхідний і достатній мінімум виразних засобів, оптимально узгоджується з уявленнями про низькому рівні програмування. Предмет моїх нагальних інтересів полягає в знаходженні найбільш ефективного способу розподілу КП — тобто завдання полягає в тому, щоб визначити 16-розрядну систему машинних інструкцій, найкращим чином корелює з принципом необхідності і достатності («є все що потрібно і немає нічого зайвого»). На першому кроці цю кореляцію можна простежити чітко і однозначно, визначивши 5 необхідних і достатніх елементів, що забезпечують повноцінне функціонування програми:

1. PC (Program Counter — програмний лічильник) — відображає принцип покрокового виконання програми в напрямку збільшення адреси виконуваної команди. Ось стандартна послідовність дій з програмним лічильником: відправляємо АЛУ на «поталу» команду, код якої міститься у клітинці АЗУ, на яку вказує PC; після чого інкрементуємо PC (тепер він вказує на наступне після коду виконуваної в даний момент інструкції слово адресної пам'яті).

2. SP (Stack Pointer — вказівник на вершину стека) — відображає принцип побудови програми, що передбачає її оформлення у вигляді ієрархічної структури підпрограм. Як наслідок, повинен запам'ятовуватися адреса повернення в те місце, звідки підпрограма була викликана, а оскільки ці виклики можуть бути вкладеними, необхідно відвести якусь ділянку пам'яті під зберігання всіх цих адрес. Звідси — організація стека за принципом LIFO (акронім Last In, First Out, «останнім прийшов — першим пішов») і два принципових способи його використання: «заштовхування» поточного адреси в стек ( PC --> (-SP) ) і «виштовхування» його звідти назад в програмний лічильник ( (SP+) --> PC ). Можливі й інші способи використання стека, але ці дві дії є необхідними для забезпечення можливості структурування програми класичними засобами. Примітка: тут і надалі знаки преддекремента (-) і постинткремента (+) будуть ставитися безпосередньо перед або після того, до чого вони застосовуються — далі по тексту будуть наводиться різні типи адресації, серед яких зустрічаються випадки неоднозначного їх інтерпретування при використанні мнемоніки асемблера процесорів PDP-11, який при першому розгляді буде корисний в якості базового прототипу.

3. STATUS — містить прапори, необхідні для умовних переходів. Умова — воно або дотримується, або не дотримується, і для того, щоб це визначити, потрібні прапори стану. Обов'язкових прапора, відображають результати найпростіших математичних дій, всього три: нуль/нуль, позитивний/негативний, є перенесення/немає переносу (останній потрібен щоб не губилися біти, вылезающие за межі комірки пам'яті). Для сумісності з 16-розрядною архітектурою регістр статусу звичайно ж зручно розширити до 16-ти прапорів, яким буде нескладно надалі знайти застосування, однак на першому етапі формалізації я виділяю елементи, відповідно, лише першій мірі необхідності. Сюди ще треба додати згадані вище два прапори, шляхом перемикання яких можна адресувати крім пам'яті коду додаткове АЗУ — сторінку даних. Решта 11, розподіл функцій яких потребує більше фантазії, ніж це допустимо на першому кроці формалізації, виносяться поки за рамки розгляду.

4. R-егистры загального призначення — грають роль локальних змінних, що забезпечують нагальні потреби виконуваної в даний момент підпрограми. Можуть також передавати значення між подпрограммами, взаємодіяти зі стеком, адресувати пам'ять, одним словом, на відміну від перших трьох — неспециализированы. Над їх кількістю довго замислюватися не доводиться: 16 штук оптимально не лише з ідеологічних міркувань, але і тому, що маючи певний досвід програмування на асме можу сказати, що 8 мало (як правило ці регістри в програмі «нарозхват», тому при такій їх кількості багато коду йде на тимчасову пересилку їх значень в стек і назад), у той час як 32 регістра для локальних функцій — це вже надмірність (зберігати значення змінних можна ж і в АЗУ). Далі для стислості регістри загального призначення будуть позначатися РОН-ами, а спеціального — відповідно РСН-ами.

5. Interrupt — переривання від зовнішніх пристроїв. Оскільки обумовлена система команд абстрагується від зовнішніх інформаційних потоків, про переривання тут досить знати, що воно може статися в будь-який момент, необхідна підпрограма для його обробки (відповідно — вказівку адреси, з якої вона починається), а також можливість повернення в те місце, на якому основна програма була перервана. Щоб не плодити сутності понад необхідності і не забивати пам'ять надлишковими даними (наприклад — таблицею, в якій зберігаються адреси обробки для кожного з переривань), приймаємо нульову адресу за початок обробки будь-якого переривання, а в стек, крім адреси повернення і поточного значення регістра статусу, поміщаємо інформацію про переривання. Якщо цієї інформації недостатньо для визначення необхідних дій по обробці переривання, додаткова інформація може бути завантажена в адресуемую пам'ять допомогою використання команд(-и) з безлічі G. Збільшення навантаження на швидкодію в порівнянні зі способом, використовують таблицю адрес, несуттєво — просто в обробник переривань, розташований за нульовим адресою, доведеться додати деяку кількість перевірок і умовних переходів, які організовують розгалуження за номером переривання, поміщеного в момент його виникнення на вершину стека. Самі перевірки можна розташувати в порядку пріоритетності перевіряються номерів — так щоб переривання з найбільшою частотою відволікання процесора і вимагають обробки в першу чергу перевірялися відповідно першими. Ці незначні витрати на швидкодію з надлишком компенсуються властивістю монолітності сторінки АЗУ, що містить виконуваний код, що добре позначається на цілісності програмної реалізації. До того ж, всі внутрішні інформаційні потоки будуть зосереджені в трьох спеціалізованих регістрах і R регістрах загального призначення — чого необхідно і достатньо для забезпечення базової функціональності низькорівневих засобів програмування. Так архітектуру процесора найлегше утримати в голові, а пам'ять може бути розподілена яким завгодно чином — лише б з нульового адреси йшов виконуваний код, а не дані, ну і ще програма повинна коректно обробляти переривання в разі, якщо такі передбачені. На момент запуску процесора всі регістри обнуляються, PC инкрементируется після відправлення на АЛУ чергової команди, а SP декрементіруется перед засиланням чергового слова даних у стек — так що при початкових нульових значеннях між стеком і машинним кодом програми ніяких накладок не повинно виникати.

На цьому перший крок формалізації можна вважати завершеним, і таким я намагатимусь дати уявлення про те, скільки «важить» мегабіт КП. Якщо вам знайома архітектура процесорів PDP-11, подальші розрахунки буде простіше візуалізувати. У стародавні часи у програмістів вони були в ходу, а потім їх витіснила ворожа ідеологія Intel-івських движків, і моєму прагненню розкопати цю тему з першопочатків багато в чому сприяла ностальгія по тим часам, коли кількість «дірок» в організації комп'ютерної архітектури було ще терпимим. З цих позицій Intel-івський асемблер можна вважати зразково-показовим прикладом того, як не потрібно робити, оскільки ключові невідповідності з пропонованих тут підходом простежуються при першому ознайомленні з його мнемонікою. Наприклад, в двухоперандной команді повинен зазначатися спочатку джерело, а потім приймач — тобто в природній послідовності, що відбиває причинно-наслідкові зв'язки між фізичними процесами, що відбуваються в «залозі». Також машинні інструкції процесора Intel не використовують в явному вигляді PC — тобто в наявності явні ознаки CISC-орієнтованої ідеології, прагне приховати за ширмою» апаратну реалізацію машинних інструкцій. Коротше кажучи, RISC-і рулять, а СІЅС-і гоухом.

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

6. Система машинних інструкцій
Отже, в нашому розпорядженні 3 спеціальних і 16 загальних регістрів, до яких застосовується деякий безліч способів адресації пам'яті. У вихідному стані пам'ять приймається чистою і «незаплямованою» спеціалізованою інформацією, що вимагає введення якихось інших сутностей крім перерахованих на першому кроці ітерації. Процесор стартує з нульового адреси сторінки коду, послідовно виконує команди, здійснює умовні та безумовні переходи, викликає підпрограми, і нарешті відволікається на переривання (останні допустимо взагалі ніяк не відображатися на безліч А, оскільки алгоритм повернення з переривання можна запозичити від звичайного способу завершення підпрограми командою RET, який зводиться до відновлення PC і STATUS-а з стека, щоб програма змогла коректно продовжити свою роботу).

Щоб простіше було «зважити» навскидку КП, звернемо увагу на ту обставину, що більшу частину його обсягу складають машинні інструкції з двома операндами (трехоперанндные можна свідомо виключити, так як вони явно не вписуються в сторінку КП, та й не дуже-то узгоджуються з уявленням про низькому рівні). Три біта з 16-ти «відкушуються» відразу на зазначення номера команди, щоб вмістити класичну сімку { MOV, CMP, ADD, SUB, AND, OR, XOR }, втрата будь-яких була б загрожує значним упущенням можливостей, в той час як в додаванні до цього списку нових команд вже немає нагальної потреби, оскільки через них можна зробити все інше. Множення і ділення реалізуються алгоритмічно і на відміну від перерахованих команд апаратний спосіб їх реалізації на мультиплексорах є елементарним. Дана вимога доцільно зарахувати до списку прийнятих за замовчуванням рішень (скажімо — галочкою на опції «trivial instructions only» ): всі команди, складові КП, повинні бути не складніше операцій додавання/віднімання. На рівні проектування інформаційних систем ускладнювати процесор немає сенсу, оскільки з урахуванням можливості зібрати його, в ідеалі, по атомам, всі проблеми за розподілом обчислювального навантаження можна вирішити шляхом регулювання взаємного розташування процесорів в просторі, де швидкість світла буде єдиним обмежувачем швидкості їх взаємодії. Як наслідок, досягнення необхідної швидкодії буде краще здійснити шляхом збільшення числа процесорів і організації їх ефективної взаємодії програмними засобами, при тому що кожен процесор окремо в силу простоти свого пристрою здатний забезпечити достатньо високі показники швидкодії. Так що ідеологія RISC пропонованого підходу буде явно дружньої — тим більше, що місця в командному просторі і так впритул. І нарешті, головне, зручність від прийняття угоди про тривіальності складових АЛУ машинних інструкцій полягає у вирівнюванні дій по складності на фундаментальному рівні проектування інформаційних систем — в такому випадку термін «мова низького рівня» шуканим рішенням буде повною мірою відповідати.

Подальша оцінка інформаційної ємності КП буде спиратися на уявлення про те, що 7/8 його обсягу займають інструкції з двома операндами, один з яких представлений в коді команди полем адресації джерела, а другий — полем адресації приймача. Поле адресації повинно містити вичерпну інформацію про регістрі, через який здійснюється адресація, а також про самому способі адресації. Регістрів всього 19, тобто на зазначення номера регістра потрібно за усередненою оцінкою log2(19) біт. Три біта пішло на зазначення номера команди, решта 13 дають два поля адресації по 6.5 біт на кожен, так що навскидку маємо 2 ^ [ 6.5 — log2(19) ] ~ 4.8 видів адресації на операнд. АЛУ процесорів PDP-11 використовує 3 біта на зазначення номера адресації і стільки ж на номер регістра — тобто включає 8 регістрів і 8 способів адресації через них, при тому що PC та SP входять в число РОН-ів. Остання властивість корисно тим, що дозволяє зробити систему команд ортогональною, і як наслідок — дає можливість окремо запам'ятовувати команди, і окремо — методи доступу до операндам (чим власне і залучали в свій час ці процесори програмістів). У даному ж випадку такий підхід неприйнятний по двом взаємодоповнюючим причин:

1. Для спеціалізованих регістрів (головним чином для PC) багато способи адресації застосовуються, оскільки ведуть або до гарантованого зависання ( (-PC) ), або до збою програми внаслідок виконання даних замість коду (ПК ). Як наслідок, КП містить інструкції, яких чимале число, формально допустимі, але на практиці незастосовні. Прямої адресації РСН-ів взагалі слід уникати — з точки зору адресації в цьому полягає їх принципова відмінність від РОН-ів, для яких пряма адресація вважається природною, в той час як використання РСН-ів з метою тимчасового зберігання значень зі зрозумілих причин неприйнятно. Тобто для PC та SP початком відліку є непряма адресація, а не пряма, адже перш за все нас цікавить не саме значення цих регістрів, вміст клітинки, на яку він посилається. Сказане не означає повного виключення з АЛУ можливості прямої адресації РСН-ів, і якщо програмісту потрібно, скажімо, відновити стек безпосередньо або перестрибнути далі, ніж це дозволяють локальні переходи, то для таких цілей мають бути передбачені відповідні інструкції. Різниця полягає в тому, що ці інструкції будуть проходити в системі команд не на загальних підставах, а у вигляді невеликого числа спеціалізованих («поштучних») команд, щоб не навантажувати КП і виключити практично малоприменимые способи адресації. Візьмемо, приміром, застосування до PC та SP побітових операцій AND, OR і XOR — гіпотетично така можливість допустима, але потрібно чимало фантазії, щоб придумати ситуацію, коли така необхідність виникне (а якщо і виникне, то з цього буде випливати лише те, що доведеться зробити те ж саме двома командами замість однієї). Таким чином, використання в програмі РСН-ів має свою специфіку, згідно з якою має визначатися безліч допустимих дій над кожним з них. Є й інші принципові відмінності від набору команд PDP-11, з-за яких подальше його зіставлення з визначеною тут реалізацією АЛУ буде менш показовим.

2. Друга причина, як вже було сказано, полягає в тому, що в КП занадто мало місця, щоб можна було дозволити собі так їм розкидатися, як це було описано в попередньому пункті — у зв'язку з чим ортогональний набір команд доведеться скасувати. Збільшення числа РОН-ів з 6-ти (PDP-11) до 16-ти призвело до скорочення числа способів адресації з 8 до 4.8 в середньому на операнд, внаслідок чого адресація стала «вузьким місцем» 16-розрядний АЛП, що використовує в цілому 19 регістрів. Наприклад, для РОН-ів в командне простір поміщається лише 4 стандартні типи адресації: R ®, (R+), (-R). В принципі, в більшому їх числі особливої потреби не виникає, оскільки подвійна непряма адресація (взяття адреси за адресою) з вищезазначених причин актуальна лише для PC та SP. А про решту, включені до складу 8-ми PDP-шних адресацій, можна сказати, що вони б не завадили, але якщо їх виключити, то це не буде великою втратою зважаючи нетиповості фігурування РОН-ів в інших типах адресації. Взагалі кажучи, для PC застосовні лише два способи адресації: (PC+) і &(PC+) (перший називається «непряма автоинкрементная», другий — «подвійна непряма автоинкрементная»). Постинкремент необхідний для того, щоб перестрибнути через слово даних після його взяття АЛУ на обробку — щоб уникнути виконання випадкової команди, призначеної для виконання наступної. Як наслідок, перший спосіб адресації за змістом означає взяття константи — значення, яке перебуває у момент виконання команди в комірці, розташоване в АЗУ слідом за кодом цієї команди (назвемо цю клітинку «поточної»), а другий — звернення до змінної (на цей раз в поточній комірці міститься адресу комірки, де зберігається значення змінної — звідси подвійна косвенность). Використання першого виду адресації має сенс лише стосовно до джерела, оскільки дані зазвичай пересилаються з константи, а не навпаки — в константу. В принципі, нічого не заважає записати якісь дані по поточним адресою, але сенс це має лише в тому випадку, якщо передбачається подальше їх використання для чого необхідно знати адресу поточної комірки. Виходить що константа в даному випадку перетворюється в змінну, яку можна було б зберігати і в будь-якій іншій комірці — тобто на приймачі даний спосіб адресації буде надмірним, і при скурпульозному відборі адресацій згідно з критерієм корисності його слід виключити. Таким чином, якщо PC крім цих двох способів (формально їх навіть не два, а півтора) немає сенсу адресувати якось по-іншому, то для РОН-ів більшу кількість адресацій просто не поміщається в адресний простір, і якщо залишатися в рамках класичної реалізації АЛУ, то можна вважати ці способи необхідними і достатніми.

Зате на SP і STATUS в командному просторі залишається достатньо місця, щоб забезпечити більш широкі можливості їх адресації. Стек зазвичай використовується в програмі досить часто, щоб приділити йому увагу і зіставити більш солідне безліч адресацій. У поточній реалізації це набір містить 16 видів адресації, половину з якого складають адресації зі зміщенням { N(SP), N+(SP), -N(SP), &N(SP), &N+(SP), &-N(SP), &N(SP)+, &N-(SP) }, де N — байт зміщення, під який відведено половина регістра статусу — тобто величина зміщення вершини стека не може перевищувати 255. Зате на відміну від системи команд PDP-11 тут N є змінною, а не константою — що дозволяє застосовувати до нього автоинкремент/автодекремент і діставати значення з різних місць стека, залишаючи недоторканою його вершину. Як правило, нас цікавлять дані, розташовані не вище вершини стека (власне, занесені в стек, а не вищерозміщені, які зазвичай вважаються вже відпрацьованими), отже включати в діапазон величини зміщення негативні значення недоцільно. Інша половина адресацій виглядає наступним чином: { (SP), (+SP-), (-SP+), &(SP), &(SP+), &(SP), &(SP)+, &-(SP) }. Щоб уникнути плутанини в інтерпретації другого і третього елементів у списку зазначу, що це одне з небагатьох виключень асиметрії адресацій для джерела і приймача (тут для джерела передбачається пост-інкремент/декремент, в той час як для приймача — перед-. Останні дві адресації, як і в попередній вісімці, припускають використання цільової комірки стека в якості лічильника, инициализированного початковим адресою масиву пам'яті. Елементи списку підбиралися за принципом найменшої надуманості і найбільшої корисності, і на даний момент мені ця добірка, кількість елементів якої підігнано під «кругле» число 16, бачиться мені оптимальною.

Регістр статусу виявився найбільш продуктивним у плані різноманітності способів адресації. Задаючись питанням про те, як найбільш ефективно розпорядитися іншими 11-ю бітами, я прийшов до висновку, що найкраще розбити STATUS на два байти, один з яких буде містити прапори спеціального призначення, а другий — загального (за аналогією з базовою класифікацією регістрів). Кожен з байтів ділиться в свою чергу на два полубайта. Перший спеціалізований півбайт містить 4 арифметичних прапора, 3 з яких описані вище, а другий півбайт — 4 «геометричних» прапора, 2 з яких відведені під перемикачі адресуються сторінок пам'яті. Арифметичні прапори можна «добити» прапором парності, перевіряючим молодший біт результату (для симетрії зі знаковою прапором, перевіряючим старший розряд), а призначення двох інших «геометричних» прапорів зарезервовані під функції зовнішніх комунікацій, які поки не визначені. Прапори спеціального призначення (ФСП-и) виношу за рамки подальшого розгляду — з точки зору адресації тут насамперед цікаві ФОН-и, точніше — байт загального призначення, один з прикладів використання якого наведено вище (там де про адресацію SP зі зміщенням). Позначивши полубайты змінними Bx і By, представлю початковий список адресацій регістра статусу: { B, Bx, By } — тобто до байту в цілому і до полубайтам окремо застосовується прямий спосіб адресації, можна зберігати там значення і перетворювати їх на загальних підставах. Але головна мета подальшої фрагментації регістра статусу полягала в тому, щоб зберігати в полубайтах номер регістра, і як наслідок — забезпечити можливість індексації РОН-ів: { Rx, Ry, (Rx), (Ry) }. Приклад: MOV (Rx),(-SP) — переслати в стек значення змінної, адреса якої поміщений у регістр, номер якого вказаний у Bx. Тепер у РОНА-ах можна зберігати короткі масиви, посилатися на них за значенням, ну і взагалі — утворюється додатковий поверх в ієрархії доступу до пам'яті: 4-розрядний міні-регістр вказує на 2^4=16-розрядний РОН (слово), а той в свою чергу може посилатись на клітинку 2^16=65536-словного АЗУ (сторінка). Дуже корисний і перспективний наворот, що розширює можливості структурування процесів обробки даних, а також невимогливий до місця в КП. Ще одна можливість, яку я теж думаю не варто нехтувати, полягає в прив'язці полубайтов загального призначення до арифметичним прапорів (фігурують далі під індексами z, n, c, p): { Rz, (Rz), Rn, (Rn), Rc, (Rc), Rp, (Rp), Bz, Bn, Bc, Bp }. Приклад: MOV (SP+),(Rn) — взяти з вершини стека значення і переслати його в клітинку, адреса якої вказана в реєстрі, номер якого в залежності від стану прапора n знаходиться або в Bx, або в By (інші дії в списку можна визначити за аналогією). Запропонований спосіб використання полубайтов статусу суттєво підвищує виразну потужність складових командне простір абстракцій, при тому що апаратна реалізація зіставлених ним дій не виходить за рамки тривіальності, полагаемой необхідною умовою відповідності ідеології RISC. Тут, до речі, згодилося вищезазначене перевага числа 16, як «самого круглого» (для якого дотримується умова R % N = 0): номер 16-розрядного регістра можна розмістити в іншому 16-розрядному регістрі (в даному випадку — в регістрі статусу) якраз 4 рази.

На даному етапі визначення АЛУ командне простір поділено на 8 рівних частин, з яких 7 закріплені за двухоперандными командами, а 8-я відведена під інші. Наступною по ємності йде група інструкцій, які здійснюють локальні переходи і включають в свій код величину зміщення щодо місця їх виконання. Відводити під зсув менше байта немає сенсу, а більше не вийде за тією ж банальної причини браку місця. Від решти 13 біт «відкушуємо» байт зміщення, і залишається 5 біт для зазначення номера команди — тобто їх не може бути більше 32-х. І ще як мінімум необхідно виділити місце під однооперандні команди. Багато там не розкусиш» (обійтися менш ніж 24-ма командами з цієї групи важкувато), але оскільки однооперандні команди «важать» в 2 рази менше в силу того що їм потрібно 7, а не 8 біт на подання операнда, то з 8-ми команд розгалуження можна зробити 16 однооперандні — чого в умовах жорсткої економії командних ресурсів цілком вистачає. Дані показники близькі до PDP-шних, ну і досвід викладання мозаїки згідно заданих в умові цієї задачі критеріям показує, що такі оптимальні пропорції і стійкі, а саме: 7/8 командного простору займають двухоперандные команди, а решту 8-ю частину ділять між собою однооперандні команди і локальні переходи у співвідношенні об'ємів 1: 3. Повна система машинних інструкцій АЛУ не вичерпується цими трьома групами команд, але вони є найбільш ходовими в програмі, а з точки зору навантаження на командне простір — визначальними. Для решти ж (безоперандных, прапорцевих та інших, можливо не вписуються в загальний формат команд) передбачається виділення місця із залишків, незайманих таблицями адресацій трьох базових множин машинних інструкцій. Таким чином, на другому кроці ітерації отримуємо 7 + 16 + 24 + { приблизно стільки ж додаткових } команд, складових повну реалізацію АЛУ. Однозначний їх склад визначено лише в першій групі у вигляді «класичної " сімки»; склад другої групи передбачає включення в неї з десятка стандартних команд, що зустрічаються практично в будь-яких реалізаціях АЛУ, і ще декількох корисних на рівні забезпечення базових засобів низькорівневого програмування (скажімо — перестановка байтів в слові); третя група містить команди розгалуження та організації циклів в діапазоні байта зсуву; інші забезпечують додаткові зручності і гнучкість написання машинного коду. При цьому одна команда може містити в собі від 1 (безоперандные) до 8192 (двухоперандные) машинних інструкцій.

Ще не завадило б забезпечити процесор додатковими регістрами — такими як ТМС (лічильник системного таймера), TMR (регістр передустановки системного таймера, задає період відліку), РТІ (порт вводу), PTO (порт виводу) і CFG (регістр конфігурації, що містить переддільники для таймера, що регулюють його швидкість відліку; прапор дозволу переривання від таймера для забезпечення можливості тактирования процесів; також можуть виявитися корисними прапори, що забезпечують синхронізацію роботи таймера за станом портів вводу-виводу). В такому випадку доведеться додати в безліч G деяку кількість інструкцій, які здійснюють обмін даними між основними і тільки що перерахованими додатковими регістрами.

На цьому, мабуть, все — якщо не виходити далеко за межі нагально необхідних для забезпечення базової функціональності процесора елементів. Як можна переконатися з наведених розрахунків, для забезпечення прийнятної реалізації низькорівневих (RISC-орієнтованих) засобів програмування необхідно і достатньо 16-розрядного КП, і в прагненні виконати першу частину умови завдання («все необхідне») на другу («немає нічого зайвого») в КП майже не залишається місця. Так що по суті питання зводився до розподілу по групам команд і адресацій з попередніми їх виділенням та подальшим погодженням з місткістю сторінки даних.

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

1. Приймаємо розрядність фундаментальною константою, що покликана поєднати просторовий і часовий аспекти інформаційного процесу, через яку рекурсивно визначаємо трирівневу архітектуру, просторовий аспект якої задає ємність одиниці пам'яті на кожному з рівнів { слово (осередок) => сторінка (АЗП) => тому (ОЗП) }, а тимчасовий — складність процесів, ініційованих розподіленими за цими рівнями керуючими діями { машинна інструкція (команда) => керуюча прошивка (програма) => інтегрована система (власне, комп'ютер) }

2. Виходимо з уявлення про принципову можливість вичерпного опису цієї архітектури виразними засобами двох непересічних абстрактних мов, перший з яких (система позначень інформаційних каналів і вузлів, або «геометричний мову») сприяє вичерпного визначення способу взаємодії між її функціональними складовими, а другий (система машинних інструкцій, або «арифметичний мова») дає формальну базу для розробки алгоритму функціонування системи на низькому рівні.

Формально обидві мови повинні перетинатися в одній КП — тобто команди управління зовнішніми комунікаціями повинні бути включені в число оброблюваних АЛУ. Але реально останні можуть бути представлені в системі команд єдиною інструкцією, результат якої залежить від вмісту регістрів, які попередньо заноситься інформація про джерела й приймачі, обсязі пересилається, а також супутні дані, що визначають характер інформаційного обміну. Багато місця ця інформація не зажадає: 2 регістра здатні вмістити будь-який з 4-х мільярдів комп'ютерів, ще 2 — номер будь-якого з 4-х мільярдів файлів на комп'ютері, наступні 2 — вказати номер будь-якої комірки у файлі розміром до 4-х гигаслов. Тобто, для однозначної ідентифікації джерела і приймача (скажімо, в межах всесвітньої павутини і з точністю до адреси конкретного слова даних, що зберігається в пам'яті комп'ютера) знадобиться 6*2 = 12 регістрів. Ще 2 буде потрібно на те, щоб вказати обсяг пересилається, після чого залишиться 2 на розміщення уточнюючих даних — так що в 16 регістрів цілком можна вкластися. Якщо ж інформації для вичерпного опису виконуваних дій буде потрібно більше, то нічого не заважає використовувати частину регістрів в якості покажчиків на блоки пам'яті, розміщені в АЗУ.

Таким чином, всі інструкції КП, крім однієї і можливо ще незначного числа, повністю абстрагуються від зовнішніх комунікацій, так що їх «зона видимості» вичерпується 16+3 регістрами і двома сторінками АЗУ — завдяки чому стає можливою розробка «арифметичного» і «геометричного» мов незалежно один від одного. При першому розгляді (за замовчуванням) на опціях «моноканальность» і «монокомандность» можна поставити галочки, маючи на увазі при цьому, що весь виконуваний код пишеться на одній версії асемблера, а всі принципи зовнішніх комунікацій, що проектуються на вміст РОН-ів перед викликом CMD, прописані одним списком угод. На рівні проектування системи зняття першої галочки просто означало б можливість вибору АЛУ для кожного процесора зі списку альтернативних версій — лише б в склад всіх цих АЛУ була включена інструкція CMD і 16 РОН-ів, здатних вмістити інформацію, необхідну для вичерпного опису всіх видів комунікацій, підтримуваних апаратної («геометричних») складової модельованого процесу. Тобто питання про уніфікація АЛУ, як способу опису програмної («арифметичної») складової, менш принциповий, оскільки на відміну від процесорів і прилеглих до них низькорівневим засобів формалізації цього процесу, схема комунікацій з міркувань архітектурної цілісності повинна бути представлена в системі лише в однині. На рівні проектування завершених архітектурних рішень цей момент відображає природну послідовність дій при відключенні опцій «моноканальность» і «монокомандность»: створюючи новий проект вибираємо спосіб опису схеми комунікацій (задає формат файлу, який містить вичерпний опис інформаційної моделі), а по мірі додавання в цю схему нових процесорів визначаємо для кожного з них систему команд зі списку наявних реалізацій асемблера.

Розробка «геометричних» засобів формалізації двійкових технологій має свою специфіку, відмінну від «арифметичних». Якщо безліч машинних інструкцій має вкластися в конкретний обсяг КП (і по суті висловлені в попередньому параграфі міркування були покликані переконатися в тому, що 16-ти біт, хоч і впритул, але вистачає для розміщення там повноцінного RISC-орієнтованого асм-а на 16-ти РОН-ах), то щодо «геометричного» аспекту не існує об'єктивних обмежень на кількість складових його мовних одиниць. Тим не менш, це кількість теж повинно прагнути до необхідного мінімуму, і принцип «є все потрібно, немає нічого зайвого» тут не менш актуальне, оскільки формальна база, на якій передбачається створення наступних поверхів формалізації інформаційного процесу, повинна задовольняти вимогам компактності і легкоусвояемости. Вважаю, що в цій області теж можна шляхом нехитрого аналізу знайти класичне рішення, яке при мінімумі інформаційних витрат і обмежень можливостей побудови формалізованої моделі інформаційного процесу забезпечило надійність функціонування та зручність проектування створюваної на базі цієї моделі архітектури.

Автоматизація фізичного конструювання інформаційних систем є приблизно наступним кроком на шляху розвитку інформаційних технологій, а складність системи, що забезпечує такі можливості, приблизно на порядок перевищує поточні досягнення. В силу цих причин стає значною перешкодою надлишкова інформація, призначена для вирішення проблем сумісності на всіх рівнях організації системної архітектури — як це водиться при стихійному розвитку мов і рівнів формалізації інформаційних процесів. Тут я намагався розставити лише ключові акценти, варіюючи в деяких межах ступенем жорсткості прийнятих обмежень — так щоб прибираючи в зворотному порядку проставлені в «опціях за замовчуванням» галочки (власне, це «двоичность», «моноразрядность», «моноканальность», «монокомандность» і «RISC-орієнтована архітектура»), можна було б повернутися в кореневу директорію "/Логіка".
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.