Розглянемо окремо машинні ко-ман-ди МП, специфічні для кожної кон-к-ретної моделі або введені для су-міс-но-с-ті зі старими, знятими з виробництва моделями МП, програми для яких ще використовуються третіми фірмами. Якщо порівняти систему команд роз-пов-сюджених RISC архітектур: Digital Alpha, HP PA RISC, IMB & Motorola PowerPC, Silicon Graphics MIPS/MIPS16, Sun MicroSystems SPARC, Advanced RISC Machines ARM/Thumb, Hitachi Super, Mitsubishi M32R [10] з ADSP-21060, то в різноманітності системи ко-манд останній перевершує перелічені архітектури. Чіткої структури в системі команд ADSP-21060 не простежується: предикатне виконання команд дос-туп-не лише для частини довгих команд, од-ночасний доступ до обох просторів пам'яті гарвардської архітектури об-ме-же-ний, архітектура є перехідною від простого ПЦОС до ПЦОС з ДКС — практично використання ДКС дозволяє тільки одночасно робити одну-дві арифметичні операції та звертання до пам'яті.

Розбіжності між різноманітними серіями МП з ДКС та ПЦОС з ДКС доз-воляють машинно-незалежно ор-га-ні-зувати тільки загальні частини ком-пі-лятора — генератор проміжного коду, аналізатор індексних та охоплюючих змінних в циклах [11, ], від-слід-ко-ву-ван-ня потоку даних, формування дов-гих команд у генераторі коду, прог-рам-ний конвейєр, але не перетворення про-міжного коду в команди цільового процесора і не формування команд з про-міжного коду. Недоцільно робити ста-тичними синтаксичний і лексичний аналізатори мови високого рівня (МВР), тому що стандартні мови C, Pascal і Fortran не дозволяють роз-мі-щувати у тексті програми директиви векторизуючому компілятору, необ-хід-ні для коректної генерації коду: вка-зів-ки просторів пам'яті, абсолютні адреси, апаратно-залежні змінні (volatile), по-ря-док розташування трас в операторі IF.

Для можливості оперування різ-но-манітними МП необхідно всі описи процесорів, оптимізацій, настроювань, особливостей МВР виносити в окремі структури.

Таким чином, векторизуючий ком-пілятор системи "Святогор" являє собою: 1) загальну частину, що скла-да-єть-ся із синтаксичного та лексичного аналізаторів, генератора проміжного ко-ду, оптимізатора, генератора коду; 2) бібліотеку пристосувань (експертну систему), що оперує таблицями порад; 3) кілька мов для опису різноманітних пристосувань.

Різноманітні настроювання, які не мають регулярної структури, не мож-на назвати повноцінною ек-спер-т-ною системою [13]: деякі є пов-но-цін-ни-ми описами архітектури та особ-ли-вос-тей процесора проміжною мовою,
а дея-кі — простими константами або таблицями. Але функціонально усі во-ни є порадами у формі "якщо–то", і ця система порад подібна до описів пра-вил продукцій у продукційних ек-сперт-них системах. Тому далі всю систему налагоджень (та її окремі частини) бу-де-мо називати таблицями порад.

Інтеграція зовнішніх модулів
у компілятор

Звичайно компілятор розгля-да-єть--ся як єдина програма — автомат, що перетворює за визначеними пра-ви-ла-ми текст з однієї мови в іншу. Якщо вхідними даними є текст програми МВР, то результатом можуть бути об'єктний код, або асемблерний текст та лістинг, або файл повідомлень. У ви-падку генерації коду для статичної архітектури (МП класу 80x86) такий підхід себе виправдовує. Якщо мік-ро-про-цесор секційний (серія 1801) або масштабований (архітектура з кому-та-то-ром — TTA), є необхідність от-ри-ман-ня додаткової інформації з процесу ком-піляції. Вона може містити оцінку ефективності генерації коду для даної архітектури, наприклад ступінь вико-рис-тання функціональних пристроїв про-цесора, відносну кількість звертань до пам'яті, ступінь векторизації коду.
Є навіть пропозиції робити процес ге-не-ра-ції коду ітеративним.

Програму, скомпільовану в про-між-ний код, можна уявити у вигляді ієрар-хічного графа [14], а процес ком-пі-ляції — як перетворення з вхідної мо-ви у вихідну. Між початковим пе-ре-т-воренням з програми МВР в ієрар-хіч-ний граф і кінцевим, з ієрархічного графа в асемблерний код цільового процесора, над ієрархічним графом мож-на проводити оптимізуючі пере-тво-рен-ня або ж збирати статистичну ін-фор-мацію. Найкориснішою є інфор-ма-ція про оптимальну кількість функ-ціо-нальних вузлів для масштабованих про-це-сорів і про ступінь їх використання. Користь від такої інформації пов'язана з тим, що стандартні алгоритми циф-ро-вої фільтрації, швидкого перетворення Фур'є [4], згортки і т.п. добре підходять лише для стандартної архітектури ПЦОС з одним пристроєм "помно-жу-вач-суматор". Використання цих ал-го-рит-мів на МП з ДКС значно не під-ви-щує швидкість обчислень, тому що сту-пінь паралелізму в самому алгоритмі невелика — необхідне використання більш сучасних алгоритмів цифрової об-робки, наприклад швидкого пе-ре-тво-рен-ня Фур'є з блоками 4*4 замість 2*2. Оптимальним рішенням у цьому випад-ку є створення процесора, що матиме необхідну кількість помножувачів та су-маторів для функціонування ал-го-ритму.

На верхньому рівні система "Святогор" виглядає як низка викликів програм, починаючи з компілятора і закінчуючи генератором коду. Моду-лям, що викликаються після першого, вся інформація про ієрархічний граф програми передається за допомогою двох глобальних змінних — %програма та %підблоки, через які можливий доступ до ієрархічного графа. Така кон-струкція дозволяє легко вставляти блоки оптимізатора або збору інфор-мації, а також блоки препроцесорів (єдиним аргументом компілятора є гло-бальна змінна — ім’я вхідного файлу). Усередині генератора коду передбачені виклики процедур, яким передається статистична інформація. У режимах без збору статистики ці процедури є по-рожніми.

Можливість інтеграції додат-ко-вих модулів у систему "Святогор" доз-во-ляє проводити аналіз придатності ал-го-ритму для даного МП або МП для даного алгоритму. Така інформація у ви-падку автоматичної генерації опису цільового процесора мовою Verilog або VHDL дозволяє легко створювати спе-ціа-лізовані процесори (співпроцесори) для виконання певних алгоритмів або описи систолічних матриць [15]. Мож-ли-вий