Динамічно реконфігуруємий процесор

1. Динамічно реконфігур уємий процесор, що має пристрій пам'яті і набір програмуємих логічних пристроїв, який відрізняється тим, що програмуємі логічні пристрої, що утворюють реконфігуруємий блок обробки даних, пов'язаний за допомогою поєднань з ядром процесора, яке містить блок мікропрограмного керування, схему трансляції адреси, блок інтерфейсу, підключеному до пристрою пам'яті, схему керування реконфігур уванням ресурсів процесора та портал, під'єднаний до реконфігур уємого блока обробки даних, програмуємий синтезатор частоти виходи якого підведені до входів синхросигналу програмуємих логічних пристроїв, мікропрограмної статичної синхронної пам'яті. 2. Динамічно реконфігур уємий процесор по п. 1, який відрізняється тим, що блок мікропрограмного керування підключено до схеми трансляції адреси, та до порталу реконфігур уємого блока обробки даних, і має три канали керування процесом реконфігур ування трьох частин реконфігуруємого блока обробки даних. 3. Динамічно реконфігур уємий процесор по п. 1, який відрізняється тим, що портал реконфігуруємого блока обробки даних має стандартизований інтерфейс, до якого підключено реконфігур уємий блок обробки даних. 4. Динамічно реконфігур уємий процесор по п. 1, який відрізняється тим, що реконфігуруємий блок обробки даних складається з трьох груп програмуємих логічних пристроїв, що поєднані між собою набором зв'язків: системного реконфігуруємого ресурсу, реконфігуруємого ресурсу задачі і реконфігур уємого ресурсу системи команд. 5. Динамічно реконфігур уємий процесор по п. 1, який відрізняється тим, що реконфігуруємий блок обробки даних вміщує системний реконфігур уємий ресурс, який залежно від його конфігурації містить у собі набір апаратних блоків обробки та передачі даних, що працюють протягом усього сеансу роботи динамічно реконфігур уємого процесора. 6. Динамічно реконфігур уємий процесор по п. 1, який відрізняється тим, що реконфігуруємий блок A (54) ДИНАМІЧНО РЕКОНФІГУРУЄМИЙ ПРОЦ ЕСОР 36719 об'єкта конфігурації з обладнанням процесора, параметр довжини контексту регістрів, параметр робочої частоти, ідентифікатор об'єкта, список ідентифікаторів інших об'єктів конфігурації, що включені в поточний об'єкт, набір конфігураційних даних і блок двоїчного опису процесора. 15. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що описувач сумісництва використовується для визначення можливості фізичної загрузки конфігураційних даних у реконфігур уємий ресурс. 16. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що довжина контексту регістрів використовується для визначення кількості слів даних, що являють собою робочий контекст поточної задачі. 17. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що параметр робочої частоти використовується для визначення максимальної робочої частоти процесора. 18. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що список ідентифікаторів вміщує ідентифікатори тих об'єктів конфігура ції, обладнання яких включено в поточний об'єкт конфігурації без змін. 19. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що за допомогою списку ідентифікаторів об'єктів конфігурацій блок мікропрограмного керування визначає наслідування поточним об'єктом, що використовується, конфігурації для усякого типа реконфігур уємого ресурсу, якостей об'єкта конфігурації, який запланований до загрузки і скасовує операцію реконфігур ування ресурсу, якщо новий об'єкт конфігурації реалізує таке ж обладнання, що і поточний. 20. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що блок двоїчних даних використовується для безпосередньої загрузки в програмуємі логічні пристрої реконфігуруємого ресурсу. 21. Динамічно реконфігур уємий процесор по п. 14, який відрізняється тим, що блок двоїчного опису процесора вміщує логічний опис структури обладнання, що представлено об'єктом конфігурації, без прив'язки до матеріальної бази процесора. Винахід відноситься до високопродуктивних пристроїв обчислювальної техніки, в яких для підвищення швидкості обробки даних використовують реконфігур уємий апаратний ресурс і реконфігуруємий набір машинних команд, які оптимізовані для кожного конкретного алгоритму. Об'єкт винаходу являє собою динамічно реконфігуруємий процесор із змінним набором команд, що дозволяє поєднати у собі універсальність процесорів загального призначення, можливість повної або часткової реалізації алгоритмів у апаратній частині в поєднанні з програмним керуванням блоками, які обробляють дані у реальному масштабі часу, а також дають можливість розробки оптимального набору команд для будь-якої задачі в широкому спектрі задач. Відомі наступні розробки у цьому напрямку. В патенті США за номером 5600845 (Gilson, Kent L. G06F15/31) наведено опис обчислювального пристрою, що вміщує в своїй основі мікропроцесор із скороченим набором команд (RISC) та логічний пристрій, що програмується -PLD, що реалізує додатковий набір команд, який зумовлений конфігурацією цього пристрою. Недоліками даного пристрою є неможливість автоматичного реконфігур ування блока обробки, так як використовується механізм реконфігур ування від зовнішньої обчислювальної системи за допомогою спеціального інтерфейсу. Найбільш близьким до винаходу за способом реконфігур ування ресурсу мікросхем PLD є винахід, описаний Патентом США за номером 5933642 (Greenbaum, Jack E. Baxter, Michael A. G06F18/18), в якому пропонується використовувати динамічне перемикання між наборами машинних команд і архітектурами блока обробки машинних команд, яке виконується на основі спеціальних інструкцій, операндами яких є покажчики на об'єкти конфігураційних даних. Об'єкти конфігураційних даних, що пов'язані в процесі компіляції з об'єктами програмного коду використовуються для програму вання мікросхем PLD, на основі яких зібрано блок обробки команд. Недоліком є необхідність використання спеціальних команд для ініціалізації реконфігурування, що перешкоджає жорстку прив'язку програмного коду до потрібної для нього системи команд, а також робить проблемним реалізацію викликів процедур обробки апаратних переривань, які також можуть використовувати різні набори команд. В патенті США за номером 5684980 Casselman Steven Mark (G06F19/00) описано віртуальний комп'ютер на базі PLD з реконфігур уємою системою команд. Цей комп'ютер є найбільш близьким аналогом до даного винаходу. Комп'ютер складається з набору PLD, між якими розташовані програмуємі комутатори, комп'ютер також вміщує набір керуючих PLD, що реалізують пристрій мікропроцесорного типу, який керує реконфігур уванням першої частини PLD і комутаторів. Комп'ютер має можливість реалізації в апаратному виді різних алгоритмів обробки даних на наборі реконфігур уємих PLD. Реконфігур ування керуючих PLD комп'ютера робиться під час початкової ініціалізації пристрою по вмиканню живлення. Недоліками даного пристрою є те, що пристрій не володіє повною мірою можливістю динамічного реконфігур ування в процесі роботи, а зміна набору машинних команд і алгоритмів їх виконання не можлива до моменту наступної фази початкової ініціалізації. В основу винаходу поставлено задачу збільшення продуктивності мультизадачної обчислювальної системи, яка має систему захисту пам'яті шляхом динамічного реконфігурування блока обробки команд і використання у процесорі реконфігур уємого апаратного ресурсу, що використовується для організації апаратних блоків обробки даних, індивідуальних для кожної задачі, що дозволяє забезпечити оптимальну адаптацію системи команд до будь-яких алгоритмам обробки да 2 36719 них, а також забезпечити виконання задачі апаратними засобами в реальному масштабі часу. Даний процесор має можливість динамічного реконфігур ування, піддержує мультизадачний режим роботи і має засоби захисту інформації від несанкціонованого доступ у однієї задачі до даних іншої. Виконання декількох задач виконується в режимі розподілу часу. Система захисту пам'яті побудована на основі об'єктів та перевірці можливості використання об'єктів в різних задачах. Будь-яка структура інформації виділяється в об'єкт, що має певні якості, які у свою чергу описуються за допомогою дескриптора доступу. Дескриптори об’єктів розміщуються у так званій дескрипторній таблиці, розміщення якої в системній пам'яті визначається за допомогою одного з системних регістрів керування. Звертання до любого елементу даних або програмного коду виконується за допомогою логічної адреси, що складається з двох складових - зміщення та селектора. За допомогою селектора виконується вибірка дескриптора із системної дескрипторної таблиці, а за допомогою зміщення виконується адресація необхідного елементу всередині об'єкта. Трансляція логічної адреси у фізичний і перевірку можливості використання об'єкта при зверненні по даним і при вибірці машинних команд здійснює блок обробки транзакцій. Перевірку правил передач керування, перемикання між задачами здійснює блок мікропрограмного керування. Система захисту пам'яті і підтримки мультизадачної обробки дозволяє захистити набори даних різних задач і операційної системи від несанкціонованого доступу та помилкової модифікації. Крім цієї функції, на основі системи захисту пам'яті реалізована система реконфігур ування апаратного ресурсу процесора. Для реконфігур ування апаратури процесора використовуються набори даних, що зберігаються в об'єктах спеціального типу - об'єктах конфігурації. Динамічно реконфігуруємий процесор виконано на основі мікросхем PLD, що виконані по так званій SRAM-те хнології. Вузли обробки даних, що реалізують функції інтерфейсу системної пам'яті, блока мікропрограмного керування, блока обробки команд, пристрої обробки даних і т.п. формуються в мікросхемах PLD шляхом загрузки в них набору бітів конфігураційних даних. SRAM - технологія, на якій основані PLD, дозволяє багатократно змінювати конфігурацію пристроїв і склад, функції і призначення пристроїв обробки даних і систему команд процесора. Описаний процесор вироблений на наборі PLD, поділений на чотири категорії ресурсів PLD. 1. Ядро процесора - та частина мікросхем PLD, які конфігур уються одноразово, на початку сеансу роботи і реалізують жорстко визначене обладнання, необхідне для сервісної підтримки системи захисту пам'яті, перемикання задач, контролю передачі керування між програмними модулями, вибірки машинних команд і пересилки даних. 2. Системний ресурс - використовується для формування апаратних блоків, необхідних для взаємодії з пристроєм контролера локальної мережі і для будь-якої іншої обробки даних. Склад обладнання в системному ресурсі не залежить від складу задач, що виконуються, і конфігурації набору команд. 3. Ресурс задачі - використовується для створення апаратних модулів, необхідних для функціонування тої чи іншої задачі незалежно від виконуваного програмного коду і його системи команд. Ці пристрої обробки даних в реальному масштабі часу, індивідуальні для кожної задачі. 4. Ресурс системи команд - використовується для створення апаратних засобів, що реалізують довільну систему команд, оптимізовану для рішення певного алгоритму обробки даних. Кожний ресурс реконфігур ується відповідним способом і має свій "час життя" - інтервал часу між двома сусідніми операціями реконфігур ування. Ресурс ядра конфігур ується тільки один раз при початковій ініціалізації процесора після вмикання живлення. Системний ресурс може неодноразово конфігур ува тися за час сеансу роботи процесора. Реконфігурування ресурсу виконується за допомогою блока мікропрограмного керування тоді, коли в спеціальний системний регістр керування записується новий селектор об’єкта конфігурації для системного ресурсу. Реконфігур ування процесора на рівні ресурсу задач Для реконфігур ування ресурсу задач використовується механізм переключення задач. Кожна задача має так званий об'єкт стану задачі, що використовується для тимчасового зберігання контексту регістрів загального призначення і визначених користувачем буферів пам'яті, що організуються всередині блока обробки команд або всередині блоків обробки, що відносяться до ресурсу задачі. Об'єкт стану задачі описується спеціальним типом дескриптора доступу. Об'єкт стану задачі використовується для підтримки мультизадачної обробки у режимі розподілу часу. В дескрипторі доступ у об'єкта стан у задачі вказується селектор об'єкта конфігурації, що використовується для реконфігур ування ресурсу задачі. Селектор об'єкта конфігурації використовується тільки у моменти переключення між задачами. Реконфігур ування системи команд Зміна конфігурації системи команд виконується під час передачі керування, що супроводжується зміною об'єкта коду. Така передача керування може бути розпочата у чотирьох випадках: у випадку виникнення апаратного проривання, коли керування потоком команд з поточного виконуваного кодового об'єкта необхідно передати на процедуру обробки переривання; у випадку виникнення виключної ситуації при порушенні правил захисту пам'яті ядро процесора виконує виклик процедури обробника помилок операційної системи; у випадку виконання в блоці обробки команд операції передачі керування на другий об'єкт коду - виклик процедури або повернення з процедури; у випадку генерації запиту на передачу програмного керування в апаратурі блока обробки даних і команд, незалежно від поточного потоку команд при виявленні визначеної розробником умови. Конфігурація ресурсу системи команд описується, як і в попередньому випадку, за допомогою спеціальної позиції у дескрипторі доступу об'єкта коду. 3 36719 Таким чином, з кожною задачею та кожним об'єктом коду пов'язаний необхідний для правильного їх виконання об'єкт конфігурації. Контроль за реконфігур уванням ресурсу задач і ресурсу системи команд повністю здійснюється ядром процесора, а не програмним кодом, що виключає ситуації при яких програмний код або задача починають виконуватись в оточенні невідповідного до них набору апаратних засобів. Для виключення втрати робочих даних, що знаходяться у регістрах процесора та буферах пам'яті, використовується механізм збереження поточного контексту перед реконфігуруванням ресурсу і відновлення контексту після реконфігурування. Це дозволяє у новому об'єкті коду, що використовує нову систему команд, застосовувати дані, що підготовлені у регістрах процесора при виконанні попереднього кодового об'єкта. Ме ханізм наслідування Ме ханізм наслідування призначений для зменшення кількості операцій реконфігур ування у тих випадках, коли запропонована нова архітектура ресурсу задач або системи команд повністю сумісна з поточною. Наприклад, новий об'єкт коду може використовувати набір команд, що є частиною набору команд, що підтримується поточною конфігурацією системи команд. На рівні ресурсу задач механізм наслідування відкриває можливість згрупувати об'єкти конфігурації усіх активних задач в один загальний об'єкт по мірі активізації задач. На решті ресурс задачі буде вміщувати у собі обладнання, що необхідне для всіх активних задач, яке працює у реальному масштабі часу і незалежно від процесів перемикання між задачами на програмному рівні. Такий режим роботи дозволяє організувати апаратну обробку потоків даних у реальному масштабі часу в декількох задачах одночасно, а переключення між задачами використовувати для періодичного виклику програмних процедур моніторингу процесу обробки даних в обладнанні кожної задачі. На рівні ресурсу системи команд механізм наслідування може використовуватись для об'єднання властивостей систем команд, що найбільш часто використовуються, в загальну систему команд, що дозволяє знизити кількість операцій реконфігурування і виробити загальну систему команд для певної групи об'єктів коду. Об'єднання декількох об'єктів конфігурації в один виконується за допомогою спеціальних розділів даних, що вміщуються в об'єктах конфігурації. Ці розділи вміщують апаратно - незалежний двоїчний код опису логіки роботи апаратури процесора - мова двоїчного опису процесора (Binary Processor Description Language - BPDL). BPDL опис процесора, що генерується на етапі компіляції вихідного текстового опису з перевіркою синтаксису, складу змінних, методи використання змінних і дійсності вказаних операцій над змінними. При групуванні декількох об'єктів конфігурації в один системне програмне забезпечення процесора використовує BPDL усі х необхідних об'єктів. Формується сумарний BPDL-блок, який транслюється у текстовий файл відповідно із синтаксисом промислової мови опису обладнання (Hardware Description Language - HDL). Сформований з BPDL-блоків HDL-текст поступає на обробку в компілятор, що генерує набір конфігураційних даних з ура хуванням фізичної матеріальної бази, що використовується в процесорі. Здобуті конфігураційні дані і сумарний BPDL-блок утворюють новий об'єкт конфігурації. Розробка апаратно-програмного забезпечення. Розробка апаратно-програмного забезпечення може вироблятись з використанням мови С або Pascal. Компілятор С/Pascal виробляє розділ часток алгоритмів обробки даних на апаратну реалізацію і програмну реалізацію. Апаратна частина трансформується в текстову форму мови опису процесора, а програмна частина алгоритму - в асемблерний текст, що використовує один або декілька наборів команд, що сформовані в процесі генерації опису апаратної частини. Далі обидві частини текстів компілюються паралельно. На основі текстового опису процесора формується двоїчний опис - BPDL. Генерується набір блоків конфігураційних даних. Компілятор асемблера, що настроюється, використовуючи опис системи команд і їх форматів, виконує компіляцію програмного коду. Лінкер формує результуючі об'єкти коду і об'єкти конфігурації. Наявність проміжної ланки між вхідним текстом на мові високого рівня С або Pascal і результуючими об'єктами у вигляді вихідних текстів асемблера і опису апаратури процесора дозволяє при необхідності виробляти ручну корекцію програмного коду, системи команд або обладнання перед кінцевим етапом компіляції. На фіг. 1 представлена структурна схема динамічно реконфігуруємого процесора і зв'язку між основними блоками. На фіг. 2а показано формат дескриптора доступу, що використовується для опису об'єктів даних, коду об'єкта стан у задач. На фіг. 2б показано формат вентиля виклику, що використовується для виклику процедур. На фіг. 3 показана діаграма, яка пояснює принцип розміщення об'єктів даних у пам'яті і методику звернення до об'єктів. На фіг. 4 представлена структура об'єкта стану задачі, який використовується для тимчасового зберігання контексту регістрів процесорів при переключенні між задачами і при зміні конфігурації блока обробки команд. На фіг. 5 показана структура блока конфігураційних даних, в якому виділені основні часини, за допомогою яких виконується перевірка необхідності і можливості реконфігурування ресурсу, формування потоку даних, що передаються в програмні логічні пристрої у процесі реконфігур ування, а також блок даних двоїчного опису процесора BPDL. На фіг. 6 представлена блок-схема алгоритму реконфігур ування одного з ресурсів процесора. На фіг. 7 - структурна схема організації програмного забезпечення обчислювального комплексу, що використовується на етапі розробки і налагодження апаратно-програмного забезпечення процесора. Процесор складається з набору пристроїв пам'яті, що утворюють собою системну пам'ять, до складу якої входять блоки оперативної пам'яті (статистичного або динамічного типу) і енергонезалежна електрично репрограмуєма пам'ять, набору мікросхем PLD, блока мікропрограмної пам'я 4 36719 ті і схеми конфігур ування ядра. Основою для побудови динамічно реконфігуруємого процесора є PLD, що випускається корпорацією Altera (Altera Corporation, San Jose,CA.), родина FLEX10K і АРЕХ20К. Представники вказаних родин PLD володіють достатніми внутрішніми ресурсами як по кількості конфігуруємих логічни х блоків (Configurable Logical Block - CLB), так і по кількості виводів, необхідних для організації поєднань серед мікросхемами, які вміщують високу кількість ліній, а також по об'єму блоків внутрішньої пам'яті (так звані Embedded Array Block - ЕАВ в FLEX10K або Embedded System Block - ESB - в АРЕХ20К), що використовуються для організації регістрових файлів, черг і дескрипторного кеш, що використовується в блоці обробки транзакцій. Логічні функції обробки даних, а також поєднання між логічними елементами визначаються набором конфігураційних біт, що записуються в масив пам'яті в процесі реконфігур ування PLD. Генерація двоїчних конфігураційних даних для PLD виконується за допомогою компілятора, розробленого корпорацією Altera -"Ma x-Plus II" або "Quartus" ("Max Plus II" та "Quartus" є торгівельними марками Altera Corporation). Масив конфігураційної пам'яті засновано на елементах статичної оперативної пам'яті, що дозволяє багаторазово змінювати конфігурацію PLD. Представники вказаних ви ще родин PLD не мають засобів, які дозволяють зберегти стан елементів пам'яті у процесі реконфігур ування, що потребує організації всередині процесора апаратно-мікропрограмних засобів, необхідних для зберігання і відновлення контексту програмнодоступних регістрів в оперативній пам'яті на момент зміни конфігурації реконфігур уємого ресурсу. Загальний ресурс PLD - блоки поділяться на чотири категорії ресурсів обладнання. 1. Ресурс ядра процесора - блоки 1 і 2. 2. Системний ресурс - блок 3. 3. Ресурс задач - блок 4. 4. Ресурс системи команд - блок 5. Останні два ресурси 4 і 5 умовно поєднуються під загальним поняттям реконфігур уємого ресурсу користувача. Ресурси 5, 4 і 3 поєднані між собою зв'язками 6, 7 і 8 безпосередньо на платі процесора. Ці лінії використовуються для організації швидких поєднань без використання локальної шини 9. Поєднання дозволяють розробляти набори команд, що працюють безпосередньо з системним ресурсом 3 або ресурсом 4 для програмного моніторингу стан у пристрою обробки даних у реальному масштабі часу. Схема конфігур ування ядра 10 використовується на етапі початкової ініціації процесу, коли жоден з реконфігур уємих ресурсів не завантажений дійсною конфігурацією. Схема конфігур ування ядра 10 складається з однобітної електрично репрограмуємої пам'яті (технологія FLASH) 11, що випускається корпорацією Atmel, наприклад AT45D041, та однокристального мікроконтролера 12. Як однокристальний мікроконтролер використай PIC16F84 виробництва корпорації Microchip. В процесі початкової ініціалізації мікроконтролер 12 вичитує потік бітів конфігураційних даних з послідовної пам’яті 11 і передає цей потік в PLD ядра. За допомогою мікроконтролера 12 виконується завантаження конфігурації в PLD блока мікропрог рамного керування 2 і блок обробки адреси 1. Конфігуровані дані передаються в PLD крізь набір ліній керування конфігур уванням 13. Лінії керування і даних послідовної пам'яті 11 підключені також до виводів блока трансляції адреси 1. Схема 14 дозволяє в процесі роботи процесора прочитати конфігураційні дані ядра, BPDLопис ядра і загрузити в енергонезалежну пам'ять 11 новий код конфігурації ядра, який буде використай при наступній початковій ініціалізації процесора. Блок мікропрограмного керування 2 містить: схему керування мікропрограмною пам'яттю 15; арифметико-логічний пристрій 16 адаптований для рішення алгоритмів переключення задач, роботи з дескрипторними таблицями, апаратними перериваннями і програмною передачею керування; регістровий файл 17, який вміщує проміжні регістри, що підтримують роботу АЛУ 16, що вміщує системні регістри, доступні для блока обробки даних через портал 18; схему керування процесом реконфігурування ресурсів процесора - системного, задачі і блока обробки команд 19. Блок мікропрограмної пам'яті 20 використовується для зберігання мікрокоду процесора, що керує роботою незмінної частини ядра процесора, який відповідає за виконання алгоритмів, спрямованих на підтримку системи захисту пам'яті, перемикання задач, реконфігурування. Блок мікропрограмної пам'яті 20 поділено на дві частини: енергонезалежну пам'ять FLASH aбo EPROM-21; статичну синхронну оперативну пам'ять - 22. Енергонезалежна пам'ять 21 має розрядність 8 біт і відповідно більший час доступу до даних, наприклад, 120 нс, що обумовлює неможливість безпосереднього її використання як джерела мікрокоду. Синхронна статична оперативна пам'ять 22 має розрядність 32 біта і має можливість вибірки 32-розрядних мікропрограмних слів на кожному такті синхросигналу, частота якого може бути в діапазоні від 50 до 150 Мгц. В енергонезалежній пам'яті 21 вміщується мікропрограмний код, який керує роботою блока мікропрограмного управління 2. Мікропрограмний код при початковій ініціалізації процесора, коли схема 10 закінчила конфігур ування ядра, переписується з енергонезалежної пам'я ті 21 в синхронну статичн у оперативну пам'ять 22. Цю операцію виконує спеціальний апаратний блок, що вбудований у блок мікропрограмного керування - блок 15. Блок 15 реалізує також функції контролера мікропрограмної адреси, що формує послідовність адрес мікрокоманд в шта тному режимі роботи ядра. Після завантаження мікропрограмного коду починає роботу мікропрограма початкової ініціалізації процесора, під керуванням якої блок мікропрограмного керування 2 вичитує 32-розрядний параметр із чарунки пам'яті з адресою 00000000h. Цей параметр вміщує інформацію про розташування дескрипторної таблиці у системній пам'яті 23. Нульовий селектор об'єкту описує нульову точку входу в дескрипторній таблиці, в якій завжди повинен розташовуватися дескриптор доступу до об'єкту стану задачі. Виникає перше переключення на системну задачу. З об'єкта стану задачі витягається селектор першого кодового об'єкта, що виконується, а таким чином, і об'єкт конфігурації, що 5 36719 використовується для конфігур ування блока обробки команд - ресурсу 5. Системна задача може взагалі не використовувати ресурс задач 4. На момент початку виконання першого об'єкту коду системний ресурс 3 не запрограмований на роботу з контролером локальної мережі і не має ні яких додаткових вузлів обробки даних. Конфігурація системного ресурсу виконується програмно, шляхом запису в регістр керування селектора необхідного об'єкта конфігурації. Запис в регістр керування здійснюється за допомогою операції пересилки операнду в системний регістр керування. В процесі виконання такої команди апаратура ресурсу обробки команд 5, використовуючи портал 18 і сполучення 24, передає запит на запис операнду до регістра керування в блок мікропрограмного керування 2. При цьому крізь сполучення 24 передається номер регістра керування, операнд і тип запиту. Блок мікропрограмного керування 2, прийнявши запит, розміщує операнд у вн утрішній регістр і за допомогою цього ж операнду, що використовується як селектор, робить вибірку дескриптора об'єкта конфігурації системного ресурсу. Після вибірки дескриптора блок мікропрограмного керування починає цикл вичитування даних з об'єкта конфігурації крізь блок обробки транзакцій і передає прочитані дані в контролер 19, який формує сигнали керування реконфігур уванням для PLD системного ресурсу і проводить побітову передачу конфігураційних даних. До блока мікропрограмного керування 2 підведені три канапа реконфігурування ресурсів процесора - системний канал реконфігур ування 25, канал реконфігур ування ресурсів задачі 26 і канал реконфігур ування ресурсу системи команд 27. Канали реконфігур ування ресурсів підключені до схеми 19. Усі три канали незалежні один від одного. Кожний канал вміщує п'ять ліній. 1. nCONFIG - сигнал початку конфігурування. 2. DCLK - сигнал, що синхронізує побітову передачу конфігураційних даних. 3. CDATA - лінія для передачі конфігураційних даних. 4. nSTATUS - лінія ознаки помилки конфігур ування. 5. DONE - лінія ознаки завершення конфігур ування. Схема 19 здійснює: генерацію сигналів початку конфігур ування; моніторинг ліній ознак помилок конфігурування і завершення конфігурування; передачу даних побітово на лінію CDATA одночасно з генерацією сигналу синхронізації DCLK. Максимальна частота сигналу DCLK складає 6 Мгц (для PLD родини FLEX10K), і швидкість передачі даних по лінії CDATA 6000000 біт/сек. Якщо як ресурс 5, 4 або 3 використовується тільки одне PLD типу EPF10K100, об'єм конфігураційних даних складе 149134 байт. Такий об'єм даних може бути переданий за час 0,199 сек. Тому особливу актуальність набуває необхідність скорочення кількості реконфігур ування, що дозволяє здійснювати механізм наслідування об'єктів конфігурації. Синтезатор частоти 28, що настроюють, призначено для генерації сигналів синхронізації, що поступають на усі вузли процесора, де це необхідно. Синтезатор частоти програмується блоком мікропрограмного керування залежно від парамет рів об'єктів конфігурації. Кожний об'єкт конфігурації вміщує параметр, що визначає максимальну тактову часто ту, на якій можуть правильно функціонувати представлені їм пристрої. В процесі завантаження нової конфігурації в будь-який з ресурсів 5, 4 або 3, блок мікропрограмного керування визначає мінімальне значення тактової частоти для перелічених ресурсів і відповідним чином програмує синтезатор частоти. До фіксованих виводів системного ресурсу 3 підключено контролер локальної мережі 29. Контролер 29 використовується для поєднання процесора з іншими обчислювальними пристроями за допомогою локальної мережі з використанням TCP/IP з'єднань. Контролер 29 вміщує так званий Media Access Controller (MAC) і блок інтерфейсу фізичного рівня, що поєднує МАС з фізичним каналом. Контролер 29 здійснює кодуваннядекодування даних, прийом і передачу Ethernetпакетів. Управління роботою контролера 29 - прийом та підготовка даних до передачі, перевірку типів пакетів, маршрутизацію пакетів підтримує блок, що формується в системному реконфігуруємому ресурсі. Організація зберігання даних в системній пам'яті. В системній пам'яті 25 інформація поділена на об'єкти, у яких розташовані програмний код, будь-які дані, що обробляються, і конфігураційні дані. Кожний об'єкт описується дескриптором доступу - спеціальною структурою даних, яка визначає параметри об'єкту: фізична базова адреса 30 визначає положення об'єкта у фізичній пам'яті; довжина об'єкта 31; рівень привілейованості об'єкта, можливості доступу до об'єкта по читанню та по запису, ознака готовності об'єкта до використання, тип об'єкта 32; вказівник на об'єкт конфігурації, який необхідно використовувати для виконання команд із даного об'єкта 33; ідентифікатор задачі. до якої належить об'єкт 34. Формат дескриптора доступу зображено на фіг. 2а. Вентилі виклику процедур мають трохи різний формат, як це показано на фіг. 2б. Замість базової адреси у вентилях виклику записується зміщення процедури що викликається 35, а замість границі об'єкта вказується селектор об'єкта коду 36, в якому розташована процедура. Вентиль виклику визначається логічною адресою точки входу в процедуру. Усі операції передачі програмного керування на другий об'єкт коду виконуються тільки за допомогою вентилів виклику. Операндом в операції передачі керування при обробці апаратного проривання, команди передачі управління, при виклику обробника помилок операційної системи є селектор виклику. Селектор виклику повинен вказувати на вентиль виклику в дескрипторній таблиці. Дескриптори доступу та вентилі виклику групуються у список - дескрипторну таблицю. Адресація до того чи іншого об'єкту виконується за допомогою двох складових - селектора об'єкта і зміщення. Селектор об'єкта використовується, як це показано на фіг. 3, для вибірки дескриптора об'єкта з дескрипторної таблиці. Зміщення визначає положення операнду всередині об'єкта. Фізична адреса операнду генерується шляхом підсумовування фізичної базової адреси, що вказана в дескрипторі доступу і зміщення. 6 36719 Для підтримки мультизадачної обробки, а також забезпечення зберігання контексту регістрів при реконфігур уванні ресурсу системи команд і ресурсу задачі, призначено спеціальний об'єкт даних - об'єкт стану задачі. Структура об'єкта стану задачі подана на фіг. 4. У позиціях 37, 38, 39 и 40 розташовуються поточні логічні вказівки команд і стека. Блок із 256 байт 41 містить образ файла регістрів флагів арифметичних і логічних операцій. Блок інформації 42 використовується для зберігання контексту 256-ти регістрів загального призначення. Перелічені вище структури інформації утворюють так звану обов'язкову частину об'єкта стану задачі, після якої слідує частина змінної довжини 43. У цій частині зберігається контекст буферів пам'яті, що організуються на рівні ресурсу задачі. Якщо ресурс задачі не має регістрів і буферів пам'яті, які необхідно зберігати при його реконфігуруванні, позиція 43 має нульову довжину. У цій чи іншій конфігурації системи команд може бути реалізована змінна кількість регістрів загального призначення. При цьому приймається погодження, що кожен регістр блока обробки команд має відповідний йому 8-розрядний регістр флагів. Різні конфігурації ресурсу задачі також можуть мати різну кількість регістрів і різні об'єми буферів пам'яті. Довжина файла регістрів загального призначення і кількість елементів пам'яті ресурсу задачі визначаються параметрами у відповідних об'єктах конфігурації. Структура об'єктів конфігурації Структура об'єктів конфігурації представлена на фіг. 5. Об'єкти конфігурації розміщені нарівні з об'єктами програмного коду і даних у системній пам'яті. Доступ до них може здійснюватись також як і до будь-якого об'єкта даних. Секція 44 уявляє собою двоїчний описувач, за допомогою якого блок мікропрограмного керування 2 визначає сумісництво об'єкту конфігурації з апаратним ресурсом, який передбачається реконфігур увати і, отже, можливість виконання об'єкта конфігурації для реконфігур ування ресурсу 5, 4 або 3. Секція 45 визначає унікальний ідентифікатор об'єкта, його двоїчне ім'я фіксованої довжини, яке використовується при перегляді секцій 46 інших об'єктів конфігурації, якщо робиться спроба використання об'єкта конфігурації. Секція 46 містить список ідентифікаторів об’єктів конфігурації, які включені у даний список конфігурації. Секція виконується для реалізації механізму успадкування. Секція має змінну довжину, у тому числі і нульову, у тому випадку, коли об'єкт конфігурації уявляє собою одне ціле і описує раніше невідоме обладнання. У тому випадку, коли об'єкт конфігурації включає пристрої, що успадковані від інших об'єктів, але змінені, тоді ідентифікатори цих об'єктів вже не можуть бути вказані у списку 46. Блок 47 містить біти конфігураційних даних, які формуються за допомогою компілятора, що поставляє фірма - виробник мікросхем PLD. Дані 47 завантажують безпосередньо у конфігураційну пам'ять мікросхем PLD. Набір даних 48 є двоїчним вихідним текстом, що описує пристрій або набір пристроїв, які представлені об'єктом конфігурації. Дані зберігаються у форматі двоїчної мови описування процесора. BPDL 48 генерується з вихідних текстових файлів проекту після перевірки синтаксису, складу використовуваних у проекті змінних і методики їх використання, що виключає можливість виникнення помилок при об'єднанні часток BPDL кількох об'єктів конфігурації або при рекомпіляції об'єкта конфігурації для іншої версії обладнання процесора. Наявність блока BPDL 48 дає можливість поєднувати декілька об'єктів конфігурації в один без втручання оператора або програміста з подальшою генерацією результуючого блока даних 47. Позиція 49 використовується для визначення довжини контексту регістрів і буферів пам'яті для ресурсів об'єктів коду і ресурсу задачі. Довжина контексту висловлюється цілим числом 32-розрядних елементів даних, які необхідно передати з процесора в об'єкт стану задачі або навпаки. Позиція 50 використовується для вказування розміру максимальної тактової частоти, з якою може працювати схема, що представлена об'єктом конфігурації. Цей параметр використовується блоком мікропрограмного керування для визначення максимальної частоти, з якою може працювати процесор при кожному реконфігуруванні ресурсів 5, 4 і 3. Перевірка успадкування У процесі обробки реконфігурування на рівні блока обробки команд або ресурсу задачі, блок мікропрограмного керування 2 перевіряє необхідність реконфігурування на основі ідентифікатора об'єкта конфігурації 45. Двоїчний список 46 поточного об'єкту конфігурації і ідентифікатор 45 нового об'єкта визначають сумісність нового об'єкта конфігурації з поточною конфігурацією процесора. Якщо конфігурація процесора підтримує обладнання, що реалізоване у новому об'єкті конфігурації, то реконфігур ування ресурсу непотрібне, і тому знижується час виконання передачі керування або переключення задач. Необхідність завантаження нової конфігурації фіксується у тому випадку, коли поточне обладнання не сумісне з обладнанням, яке представлене новим об'єктом конфігурації. Іншими словами, якщо ідентифікатор 45 нового об'єкта конфігурації не дорівнює ідентифікатору 45 поточного об'єкта і список ідентифікаторів 46 поточного об'єкта не вміщує ідентифікатор 45 нового об'єкта. Алгоритм виконуваних перевірок у процесі реконфігур ування показано на фіг. 6. Блок обробки транзакцій 1 здійснює перетворення логічних адрес, що складаються з двох компонент, у фізичну адресу. Блок 1 виконує перевірку прав доступу ініціатора пересилки даних до запитуємого об'єкта. В перевірку прав доступу входять наступні пункти: можливість виконання потребуємого об'єкта; попадання зміщення в межі указаного об'єкта; можливість виконання операцій читання або запису з об'єктом; привілейованість об'єкта і привілейованість джерела запиту; можливість доступу з поточної задачі до об'єкта по номеру задачі, що вказаний у дескрипторі об'єкта. Трансляція логічної адреси у фізичну і перевірка прав доступу виконуються за допомогою дескрипторів доступу, що вміщують ви ще наведені параметри об'єктів. Блок обробки транзакцій вміщує схему 51 в якій є набір регістрів - дескрипторний кеш, що вміщує поточні дескриптори доступу, що використовується, та апаратні схеми, що формують фізичну адресу і здійснюють перевірку прав доступ у ініціатора запиту до об'єкту даних. Форму 7 36719 вання фізичної адреси виконується шляхом складання базової адреси з дескрипторного кеш і зміщення, що надходить крізь портал 18 з реконфігуруємого блока обробки даних 5 або 4. Перевірка прав доступу полягає у порівнянні зміщення з межею об'єкта, у перевірці рівня привілейованості об'єкту і привілейованості ініціатора запиту, перевірці можливості доступу з поточної задачі до об'єкта, а також у перевірці можливості читання об'єкта або запису в об'єкт. Перевірка можливості доступ у поточної задачі до об'єкта реалізується шляхом указування у параметрах запиту номера задачі, до якої стосується цей запит. У випадку, коли запит генерується блоком обробки команд, то як номер задачі використовується вміст системного регістра, що вміщує номер поточної активної задачі. Якщо запит генерується процесом, що виконується у ресурсі задачі 4, то номер задачі для цього процесу витягається із спеціального файла регістрів задачі, що розташований у блоці обробки транзакцій. Файл регістрів адресується частиною ідентифікатора запиту, що вміщує номер процесу. У випадку порушення прав доступу цикл шини блокується, а через портал в ініціатор запиту надходить повідомлення про блокування циклу і забороні подання наступних запитів до розв'язання конфлікту за допомогою процедур операційної системи. Одночасно з блокуванням циклу шини схема трансляції адреси 51 генерує переривання у блок мікропрограмного керування 2, який виконує дії, що необхідні для виклику обробника виключної ситуації операційної системи. У випадку вдалої перевірки прав доступ у до об'єкта, сформована фізична адреса, дані і керуюча інформація, що описує тип циклу шини, передаються у схему шинного інтерфейсу 52. Схема 52 виконує операцію читання або запису операнду з відповідною до запита розрядністю. У випадку читання даних або команд, операнд, що прочитаний з пам'яті або командне слово, передаються у портал разом з ідентифікатором процесу, що викликав операцію пересилки. Ідентифікатор процесу генерується у кожному вузлі блока обробки даних і використовується для визначення джерела помилки при невдалому доступі до об'єкта або для визначення одержувача операнду при вдалому виконанні операції читання або запису. У випадку операції запису ідентифікатор може бути використай для сповіщення ініціатора запиту про повне завершення операції. Для організації конвеєрного режиму обробки запитів доступу до пам'яті використовується попереджуюче сповіщення схем блока обробки даних про завершення чергового циклу шини, яке виконується у випадку вдалого проходження перевірки прав доступу у схемі 51, ще до повного виконання транзакції. Портал ядра 18 являє собою уніфікований інтерфейс, за допомогою якого користувальна частина ресурсу процесора може обмінюватись даними з системною пам'яттю, отримувати машинні команди з поточного виконуваного об'єкта коду, а також здійснювати обмін керуючою інформацією і даними з блока мікропрограмного керування. Іншими словами, портал 18 надає набір сервісних функцій, що виконуються ядром у відношенні до користувального ресурсу. До складу цих функцій входять: 1) забезпечення доступу до системної пам'яті по даним; 2) моніторинг помилок звернення до пам'яті; 3) постачання користувального ресурсу потоком машинних команд; 4) виконання операцій програмної передачі керування; 5) виконання операцій читання/запису системних регістрів керування процесором, що розташовані у ядрі процесора; 6) підтримка операцій зберігання та відновлення контексту регістрів блока обробки при перемиканні задач і в процесі реконфігур ування системи команд та ресурсу задач; 7) забезпечення блокування передачі даних при виявленні помилок звертання до об'єктів даних і програмного коду. Портал 18 і поєднання 24 PLD ресурсів 5 і 4 жорстко призначеними виводами поєднані з порталом 18 за допомогою одного або декількох поєднань 24. Кожне з поєднань має достатню кількість ліній для передачі інформації: про тип і привілейованості запиту, розрядності операнду; операнду, для запису в пам'ять або регістр блока мікропрограмного керування 2; логічної адреси операнду, що складається із зміщення і селектора об'єкта; двоїчного тега, що складається із номера джерела запиту (порту), ідентифікатора мети транзакцій та індексу дескрипторного кеш. Двоїчний тег складається з наступних частин. 1. Номер джерела запиту або порт. Використовується для визначення пристрою, що відправив запит, що необхідно для блокування обслуговування порту, що викликав помилку звернення до пам'яті. Наприклад, в процесі активізоване виконання п'яти задач. Кожна з них має свій ресурс на рівні задач. Ресурси усіх задач зведені до загального об'єкта конфігурації і фізично розміщуються у одних і тих же PLD і використовують те саме фізичне поєднання 24 для підключення до порталу 18. У цьому випадку номер порту використовується для визначення номера задачі, що відправила запит. Номер порту використовується як індекс для списку задач, що розташований у блоці обробки транзакцій, для вилучення із списку реального номеру задачі перед перевіркою можливості доступу до запитуємого об'єкту даних. 2. Ідентифікатор мети транзакції. Використовується для визначення у операціях читання даних одержувача прочитаного із пам'яті операнду всередині блока, що генерує транзакцію. Для блока обробки команд ідентифікатором мети транзакції служить номер регістра загального призначення, в який необхідно завантажити операнд з пам'яті. Для схем, що працюють на рівні ресурсу задачі, ідентифікатор мети транзакції може використовуватись для описування одержувача операнду всередині блока обробки даних. 3. Індекс дескрипторного кеш використовується для прямої вказівки чарунки дескрипторного кеш, яка буде використовуватись для трансляції адреси. У разі, коли чарунка не вміщує дійсного значення дескриптора, блок адресної обробки 1 викличе виконання спеціальної мікропрограми у 8 36719 блоці 2, необхідної для вибірки дескриптора з таблиці і завантаженні його до вказаного індексом регістра дескрипторного кеш. При цьому дескриптор буде вибрано відповідно до селектора, що передано у запиті крізь поєднання 24. У випадку, коли дескриптор доступу встановлено у дескрипторному кеш, передача селектора об'єкта крізь поєднання 24 не є обов'язковою. Його замінює індекс дескрипторного кеш, а селектор - не використовується. Типи запитів, що передаються через поєднання 24 з ресурсів 5 і 4, розподіляють на наступні групи: запити читання або запису даних; запити запису даних в системні регістри керуванням блока 2, призначення яких заздалегідь визначено; запити читання даних з системних регістрів керування; запити передачі керування у межах поточного об'єкта коду або на інші об'єкти коду; запити запису операндів в стек; запити відновлення операндів з стека. З блока мікропрограмного керування 2 до порталу 18 також передається керуюча інформація. Передача керуючої інформації виконується у випадках: блокування роботи порту під час виникнення помилок доступу до пам'яті; блокування попереджуючого вичитування машинних команд у випадку, коли передбачається передача керування на іншу гілку програмного коду; у випадках, коли необхідно виконувати операцію зберігання або відновлення контексту регістрів і буферів пам'яті при реконфігур уванні ресурсу або перемиканні задач. Підтримка зберігання контексту регістрів і буферів пам'яті. Для здійснення операцій зберігання або відновлення контексту регістрів і чарунок пам'яті ресурси 5 і 4 повинні мати необхідні апаратні засоби. Ці засоби повинні забезпечувати послідовну передачу складового набору регістрів або чарунок пам'яті у портал 18 крізь поєднання 24 по запитам, що генерує портал 18, а також забезпечувати послідовну завантаження набору чарунок пам'яті даними крізь поєднання 24 із порталу 18. Таке обладнання автоматично, без участі розробника, створюється при декларації у вихідному PDL тексті найменованого регістра, регістрового файлу або буфера пам'яті. Це обладнання прозоре з точки зору вихідних текстів опису процесора та їх двоїчних еквівалентів. Необхідне обладнання підключається на етапі трансляції PDL опису в вихідний HDL - текст. З точки зору блока мікропрограмного керування 2 збереження (відновлення) контексту полягає в передачі у портал 2 відповідної інструкції, параметрами якої є: номер регістра дескрипторного кеш, крізь який буде здійснюватись звернення до пам'яті; номер порту реконфігур уємого ресурсу, з яким буде виконуватись обмін даними; тип операції - зберігання або відновлення; кількість елементів даних. Одержавши інструкцію з необхідними параметрами, портал 18 виконує операцію блочної передачі даних, контролюючи кількість переданих елементів даних. Розробка апаратно-програмного забезпечення На фіг. 7 наведена структурна схема комплексу програмного забезпечення, що використовуєть ся на етапі розробки і налагодження прикладних апаратно-програмних засобів для динамічно реконфігуруємого процесора. Комунікація між процесором і комп'ютером підтримується за допомогою локальної обчислювальної мережі з використанням протоколу TCP/IP, який гарантує правильну доставку інформації. Основу комплексу складає набір засобів компіляції у складі: транслятора мови C++ або Pascal - 53; конфігур уємого асемблера - 54; транслятора-компонувальника PDL/BPDL 55; компілятора HDL - 56; лінкера - 57. Транслятор 53 виконує аналіз алгоритму обробки інформації, який описаний на мові високого рівня C++ або Pascal - 58 і виконує розподіл алгоритму на апаратну і програмну реалізації. Результатом роботи транслятора 53 є набори текстових файлів 59, 60 і 61. Файли 59 - текстовий опис апаратної частини, який складено на мові опису процесора - PDL. 60 - вихідні тексти програм в асемблері, у яких можуть використовуватись різні набори машинних команд. Файли 61 - кореневі файли проекту, що визначають склад об'єктів, які входять в задачу, а також вміщують описи систем команд, що необхідні для настроювання асемблеру 54. Асемблер 54 виконує компіляцію вихідних текстів 60 з ура хуванням опису систем команд, що витягає з файлів 61. На ви ході асемблера формуються двоїчні файли програмного коду 62, а також таблиця 63, що необхідна для послідуючої роботи лінкера 57. Транслятор-компонувальник 55 реалізує наступні функції: трансляцію BPDL - опису в текст HDL 64 з формуванням файлів проекту 65; перевірку синтаксису, складу змінних, методики використання змінних і коректність операцій із змінними в текстах PDL с наступною генерацією BPDL 66; об'єднання декількох об'єктів BPDL в один загальний; оптимізацію частотних параметрів схем. Результуючі файли 66 використовуються лінкером для формування результуючи х об'єктів конфігурацій. Файли проекту 65 призначені для використання компілятором 56 в якості файлів настроювання, що визначають тип пристрою PLD, що використовується, для якого необхідно формувати конфігураційні дані, а також визначають фіксовані призначення виводів PLD і, що є опціональним, можуть фіксувати розміщення логічних елементів всередині PLD. За допомогою трансляторакомпонувальника 55 здійснюється функція компонування декількох BPDL-описів в одне, що необхідне для реалізації механізму успадкування, що описано вище. Як компілятор 56 використовується система, яка постачається фірмою-виробником PLD. В окремому випадку це "MAX-Plus II" або "Quartus" корпорації Altera. Компілятор 56 виконує кінцеву трансляцію HDL-тексту в набори конфігураційних даних 67, а також генерує файл тимчасового аналізу 68, який необхідний для визначення тактової частоти, на якій може працювати пристрій. Файл 68 використовується транслятором 55 для оптимізації структури обладнання і досягнення необхідної робочої частоти. Лінкер 57 не буде викликаний доти, поки результати компілювання не будуть задовольняти необхідну робочу часто ту. Процес оптимізації обладнання не вносить зміни в BPDL, так як останній є логічним описом архітектури бло 9 36719 ків обробки. Фізично, для досягнення необхідної робочої частоти, транслятор 55 можеконвеєризувати обробку даних за допомогою проміжних регістрів, які не будуть мати наявного відображення в вихідних текстах. Лінкер 57 здійснює формування об'єктних файлів 69, які будуть передані за допомогою програми комунікації 70 в операційну систему 71 за допомогою ТСР/ІР-поєднання. При необхідності, операційна система 71 може самостійно активізувати процес компіляції шляхом передачі по ТСР/ІР-поєднанню відповідного запиту і набору BPDL-об'єктів, які необхідно поєднати в один об'єкт і виконати його компіляцію. Розробка апаратно-програмного забезпечення може виконуватись і без використання мов високо 31 0 Базова адреса 30 Межа об'єкта 31 Селектор об'єкта конфігурації 33 Флаги 32 Ідентифікатор задачі 34 го рівня шляхом безпосереднього написання вихідних текстів 59, 60 і 61. Може бути реалізовано механізм зворотної анотації, при якому компілятор мови високого рівня не генерує набір команд і файли 59, а виконує тільки генерацію вихідних текстів 60. Необхідно зазначити, що наявність засобів розробки і компіляції об'єктів конфігураційних даних не потрібна у тому випадку, якщо розробка алгоритмічного забезпечення завершена і усі необхідні об'єкти конфігурації і програмного коду знаходяться в енергонезалежній частині системної пам'яті. У цьому випадку в системі запускається раніш визначений набір задач, необхідний для функціонування обчислювальної системи відповідно до її цільового призначення. Фіг. 1 +0 +4 +8 +12 +16 Фіг. 2а 31 0 Зміщення процедури 35 Селектор об'єкта коду 36 Не використовується Флаги 32 Ідентифікатор задачі 34 Фіг. 2б 10 36719 Фіг. 3 Фіг. 4 Фіг. 5 11 36719 Фіг. 6 12 36719 Фіг. 7 __________________________________________________________ ДП "Український інститут промислової власності" (Укрпатент) Україна, 01133, Київ-133, бульв. Лесі Українки, 26 (044) 295-81-42, 295-61-97 __________________________________________________________ Підписано до друку ________ 2001 р. Формат 60х84 1/8. Обсяг ______ обл.-вид. арк. Тираж 50 прим. Зам._______ ____________________________________________________________ УкрІНТЕІ, 03680, Київ-39 МСП, вул. Горького, 180. (044) 268-25-22 ___________________________________________________________ 13