Вас вітає Інтернет конференція!
Вітаємо на нашому сайті
МЕХАНІЗМ РЕФЛЕКСИВНОГО АНАЛІЗУ МЕТОДІВ ПЕРЕНОСИМОСТІ ПРОГРАМ НА РІЗНІ ОБЧИСЛЮВАЛЬНІ ПЛАТФОРМИ
13.03.2024 00:39
[1. Інформаційні системи і технології]
Автор: Бердник Михайло Геннадійович, доктор технічних наук, доцент, Національний технічний університет «Дніпровська політехніка»; Захаров Дмитро Ігорович, аспірант, Національний технічний університет «Дніпровська політехніка»; Стародубський Ігор Петрович, аспірант, Національний технічний університет «Дніпровська політехніка»
ORCID: 0000-0003-4894-8995 Бердник М.Г.
У сучасному світі інформаційних технологій, де вимоги до програмного забезпечення постійно змінюються і зростають, актуальність створення переносимих і гнучких систем є беззаперечною. Розроблення та впровадження механізму рефлексивного аналізу власного стану для створення власного бінарного образу середовищем виконання відповідає цій потребі, оскільки дозволяє значно спростити та автоматизувати процес адаптації програмного забезпечення до різноманітних обчислювальних платформ. Це важливо не тільки для розробників програмного забезпечення, але й для кінцевих користувачів, оскільки розширює можливості застосування програм на різних пристроях, забезпечуючи високу ефективність і оптимізацію робочих процесів. Крім того, уніфікація підходів до створення програмного забезпечення сприяє зменшенню помилок, спрощенню процесу розробки та підтримки програм, а також покращує інтеграцію нових технологічних рішень.
В роботі було розроблено механізм реалізації в середовищі виконання та інтерпретуванням. Iнтерпретування вже давно відомо своєю здатністю до виконання байт-коду на різних обчислювальних платформах без необхідності перекомпіляції. Проте, впровадження механізму рефлексивного аналізу дозволило додатково оптимізувати процес виконання коду, адаптуючи його до специфіки конкретної платформи з урахуванням її архітектури та системних можливостей. Такий підхід не тільки покращив ефективність виконання програм, але й забезпечив додаткові можливості для оптимізації бінарного образу, зменшення його розміру та підвищення загальної продуктивності системи. Впровадження такого механізму стало прикладом, демонструючи важливість і ефективність рефлексивного аналізу для адаптації програмного забезпечення до різних обчислювальних платформ.
Для реалізації здатності генерації власного бінарного образу середовищем виконання, впроваджено механізм рефлексивного аналізу програмного забезпечення та середовища виконання (власного стану). Оскільки середовище виконання поставляється у вигляді бінарного модуля, що містить код, орієнтований на машину і малопридатний для адаптації, важливо доповнити цей код інформацією про його структуру та поведінку. Така інформація, відома як метадані, дозволяє здійснити процедуру клонування бінарного образу з деякими змінами, що враховують специфіку цільової платформи. Таким чином, середовище виконання забезпечує лише механізм читання метаданих у заданому форматі. Наприклад, у випадку реалізації середовища виконання на об'єктно-орієнтованій мові програмування, метадані мають надавати інформацію про класи, їх елементи (поля, методи та їх параметри, повернені значення). Також важливим аспектом є наявність даних про імпортовану або експортовану функціональність, що дозволяє визначити можливість перенесення. У разі використання специфічної для платформи функціональності, чия реалізація не може бути переведена з байт-коду в машинний код, можливо уникнути помилок, пов'язаних з відсутністю необхідних компонентів на цільовій платформі, а на етапі аналізу стану середовища виконання виявити дану проблему.
В таблиці демонструється процедура створення образу середовища виконання для нової цільової платформи на основі опису її архітектури.
Послідовність дій, необхідних для адаптації середовища виконання:
A01. Завантаження екземпляра середовища виконання на початковій платформі. Завантаження відбувається в режимі утиліти-будівельника бінарних образів.
A02, A03. Завантаження виконуваного модуля програми, що містить байт-код і опис архітектури цільової платформи.
Таблиця
Процедура створення образу середовища виконання
A04. Перевірка адаптованості системи типів, що використовується в програмі та системи команд процесора з точки зору розміру машинного слова, можливості вирівнювання об'єктів у пам'яті та виконання обчислень з даними різних типів.
A05. Перевірка наявності імпортованої в програму функціональності, зовнішньої по відношенню до середовища виконання програм.
A06. Трасування менеджера пам'яті для перевірки можливості доступу до об'єктів програми з урахуванням обраної дисципліни планування ресурсів.
A7-9. Генерація байт-коду адаптованих версій селектора та планувальника команд, розподільника регістрів. Алгоритми функціонування даних компонентів представлені далі.
A10. Вилучення з виконуваного модуля інформації про типи, що використовуються в програмі для мінімізації розміру бібліотек, адаптацію яких потрібно включити в образ середовища виконання для цільової платформи.
A11. Визначення формату бінарного модуля середовища виконання з урахуванням вимог цільової платформи.
A12. Формування бінарного образу середовища виконання, що містить байт-код власної реалізації для можливості подальшого створення похідних образів.
Для реалізації процедури генерації коду потрібне створення адаптованих компонентів компілятора, які працюють з описом архітектури набору команд. Необхідно здійснити декомпозицію компілятора не на загальноприйнятому рівні компонентів "аналізатор вихідного тексту", "оптимізатор", "генератор машинного коду", а на більш детальному. Такі компоненти компілятора, як селектор інструкцій, планувальник інструкцій, розподілювач регістрів (англ. register allocator), мають бути адаптованими з використанням опису системи команд процесора.
Для вибірки інструкцій для заданої архітектури цільової платформи застосовується порівняння дерев. Для цього необхідно представити програму у формі абстрактного синтаксичного дерева. Визначаються правила підстановки – відношення між операціями процесора та вузлами абстрактного синтаксичного дерева. Набір правил включає багато (від одного до кількох) правил для кожного вузла дерева. Правила підстановки складаються з відповідного правила граматики, шаблону інструкцій для підстановки та вартості операції. Вартість операції дозволяє оцінити час виконання коду. Це необхідно для вибірки найбільш підходящих варіантів інструкцій з точки зору продуктивності. Шаблони інструкцій та вартість операцій описуються за допомогою мови опису архітектур і не є жорстко закодованими в селекторі інструкцій.
Після здійснення вибірки інструкцій необхідно впорядкувати їх послідовність (запланувати порядок виконання). Це потрібно для того, щоб максимально використовувати можливості процесора за конвеєризації (т.зв. паралелізм на рівні інструкцій). Реалізація планувальника інструкцій базується на класичному алгоритмі, етапи якого представлені далі.
1. Здійснити перейменування значень таким чином, щоб мінімізувати залежності інструкцій за даними.
2. Побудувати граф залежностей, обхід якого буде виконуватися планувальником зверху вниз. Для кожної операції створюється вузол, який представляє нове значення, отримане в результаті перейменування. Створюються зв'язки між вузлами, при цьому кожен зв'язок має вагу – вартість операції.
3. Здійснити пріоритизацію операцій на основі найбільшої довжини шляху від даного вузла до кореня дерева.
4. Виконати вибірку операції (інструкції) та запланувати її виконання. Для цього виконується вибірка максимально можливої кількості інструкцій з початку базового блоку. На кожній ітерації циклу, в якому переглядаються інструкції, доступні для планування, оновлюється список інструкцій, готових до виконання.
Окрім генератора коду, платформно-залежні аспекти мають бути виключені з реалізації деяких компонентів середовища виконання програм. Зокрема, це стосується менеджера пам'яті, засобів відладки та профілювання додатків.
Цей метод дозволяє забезпечити:
1. адаптацію середовища виконання до новостворених архітектур процесорів, що реалізується за рахунок використання предметно-орієнтованої мови опису архітектур.
2. адаптацію інструментальних засобів – компілятора, служб відладки та профілювання, оскільки вони є компонентами середовища виконання.
Проте, для забезпечення вищезазначених можливостей, реалізація самопереносимого середовища виконання повинна бути рефлексивно-орієнтованою. З метою забезпечення можливості аналізу власного стану та подальшої генерації адаптованих версій середовища виконання та інструментальних засобів, необхідна наявність метаданих. Відповідно, реалізація повинна здійснюватися з використанням технологій та засобів, що підтримують метадані. Прикладом може служити мова C#, що використовується спільно з середовищем виконання Common Language Runtime.
Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter
Інші наукові праці даної секції
-
ЩОДО ПИТАННЯ ПРОБЛЕМ ПРИ ПЕРЕДАЧІ СИГНАЛІВ НАДВИСОКОЇ ЧАСТОТИ
28.02.2024 14:51 -
ПОРІВНЯЛЬНИЙ АНАЛІЗ СТРАТЕГІЙ ПІДГОТОВКИ ДАНИХ ДЛЯ НАВЧАННЯ МОДЕЛЕЙ КОМП'ЮТЕРНОГО ЗОРУ НА ВИЯВЛЕННЯ ДЕФЕКТІВ
13.03.2024 13:43 -
БРАУЗЕРНЕ РОЗШИРЕННЯ НА ОСНОВІ QUIC ТА RDAP: ШВИДКИЙ ТА ЗРУЧНИЙ ДОСТУП ДО ДЕЦЕНТРАЛІЗОВАНИХ HANDSHAKE ДОМЕНІВ
13.03.2024 12:52 -
СТУПЕНІ НЕВИЗНАЧЕНОСТІ У СЕРЕДОВИЩАХ ФУНКЦІОНУВАННЯ РОБОТІВ
13.03.2024 12:36 -
ІНТЕГРАЦІЯ БЛОКЧЕЙНУ ТА ВЕЛИКИХ ДАНИХ У СИСТЕМАХ ПІДТРИМКИ ПРИЙНЯТТЯ РІШЕНЬ: ВИКЛИКИ, МОЖЛИВОСТІ ТА МАЙБУТНІ НАПРЯМКИ
13.03.2024 00:51
Конференції
Конференції 2024
Конференції 2023
Конференції 2022
Конференції 2021
