Чому MIPS включав shamt і розрізняв функцію / опкод?

Мене бентежить питання, чому дизайнери MIPS включатимуть 5 біт, призначених для зсуву, і мають окремі біти коду і функції.

Оскільки MIPS є настільки РИСК, я припускаю, що лише кілька зрушень було б виконано за допомогою декількох інструкцій, тому ці 5 біт здаються, що вони витрачають місце, коли їх можна буде негайно поставити. Я припускаю, що опкоди та функція є окремими для розрізнення інструкцій типу R- та I-, але це можна зробити, розширивши опкод на 1 біт. З обома цими інструкціями типу R може бути 22 біта. Це не спрацює, якщо інструкції типу I та J хочуть зберегти своє одразу та адресу, але обидва видаються непотрібними.

Тут відбувається декілька різних вигід.

По-перше, ми хочемо, щоб вказівки були фіксованою шириною (32-біт). Це гарантує, що інструкції кешовані та керовані сторінки, що спрощує кеш і наявність сторінки та перевірки дозволів.

По-друге, ми хочемо, щоб різні інструкційні поля ( opcode/ source regs/ immediates) мали фіксовану ширину та фіксовану позицію. Це робить їх швидше / менше логіки для декодування, і вони потрібні на ранніх стадіях трубопроводу. ( destinationРеєстр не потрібен до кінця трубопроводу, тому він може знаходитися в різних місцях Rта Iінструкціях.) Положення та ширинаfunction поля мають дещо менше значення, тому що це потрібно для управління функцією АЛУ, але це на третьому етапі трубопроводу, тому у вас є трохи часу, щоб попрацювати з ним у разі потреби.

IJJ$2^{28}$$2^{28}$I інструкцій, також приємний для авторів-компіляторів / лінкерів. (У SPARC, де в безпосередньому полі було лише 12 біт, вони повинні були додати цілий спеціальний load-highклас інструкцій з 20-бітовим негайним). )

$2^6=64$JRI

Але це залишає деяку мережу кімнати з Rінструкціями. Крім 6-розрядного коду, для специфікації реєстру потрібно лише 15 додаткових бітів, які залишають 11 біт для розширеного коду та / або суми зсуву.

Ви повинні вважати functionполе розширеним опкодом для Rінструкції. Існує лише одна Rопкод інструкції, але є 64 різні, functionsякі Rінструкція може виконувати.

Добре. У нас є 60 різних Iінструкцій та 64 різних Rінструкцій, тож куди слід поставити інструкції, що стосуються зрушення безпосередньо?

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

Багато цих рішень є більше мистецтвом, ніж наукою, але є основна логіка, яку можна помітити. Ключова мета - не зробити кількість інструкцій якомога меншою, це зробити високопродуктивну конвеєр підходив до однієї мікросхеми (щоб крихітні компанії, такі як MIPS та Sun у 1980-х роках, могли конкурувати з IBM та DEC). (Назва RISC, винайдена Девідом Паттерсоном, є дещо невдалою. Це натрапило на те, що це було мило, а не тому, що "скорочені інструкції" - це точний опис того, що насправді намагалися зробити архітектури MIPS та SPARC.) Отже, ви хочете, щоб інструкції з фіксованою шириною (і відносно невеликою, щоб ви покращували поведінку кеш-пам’яті), щоб зробити вибирання, підкачку та декодування простішими та швидшими. Ви хочете ті частини інструкції, які потрібно рано розшифрувати (opcode, два регістри джерела і знак, розширений безпосередньо) мають фіксовану ширину і у фіксованому положенні. Ви хочете, щоб прямі були якомога довші, і ви хочете якомога більше різних інструкцій, враховуючи всі інші обмеження.

Щоб зрозуміти формати інструкцій MIPS I, вам потрібно зрозуміти конвеєр MIPS, а також подумати про технологію впровадження процесора близько 1985. Якщо ви подивитеся на діаграму (ви знаєте одну), ви побачите, що зчитування файлів реєстру знаходиться в Етап ІД, відразу після ІФ.

Для вказівки типу R на етапі ID потрібно виконати такі завдання:

1. Визначити , що це на самому справі є інструкцією R-типу.
2. Якщо це так, скажіть файл реєстру, щоб завантажити значення з регістрів.

Для цього обговорення це перше завдання, про яке ви повинні подумати. Якщо є багато роботи з декодування інструкцій, яку вам потрібно зробити, щоб навіть відпрацювати, якщо вам потрібні будь-які значення з регістрів, це збільшує затримку, перш ніж ви можете запустити зчитування реєстру. Це також збільшує складність стадії ID. Зарезервувавши єдиний опкод для всіх інструкцій типу R, ви зведете складність до мінімуму.

Здається, трохи дивно, що ви присвячуєте п'ять біт саме на зміну. Я можу придумати кілька можливих пояснень. Одне полягає в тому, що це спрощує маршрутизацію (ці п’ять біт ЗАВЖДИ подаються прямо у файл реєстру; ці п’ять біт ЗАВЖДИ подаються у барабанний перемикач; ці шість бітів ЗАВЖДИ направляються до АЛУ, щоб визначити, яку функцію виконувати).

Вони, можливо, думали запровадити комбіновані інструкції зсуву ліворуч і додати в майбутньому. Це, мабуть, має форму:

$d = $s + ($t << shamt)

$2^s+1$$s$

Сьогодні ми, мабуть, не думали б двічі про складнішу стадію декодування, тим більше, що доступ до файлів регістрів, як правило, трапляється пізніше в конвеєрі типового суперскалярного процесора. Багато сучасних процесорів навіть роблять грубе декодування інструкцій під час введення інструкції в кеш-пам'ять L1 . Ви робите лінії кеш-пам'яті на кілька біт ширше, щоб зберігати додаткову інформацію (завдяки Закону Мура ви маєте багато транзисторів витрачати), щоб зробити "правильну" розшифровку інструкцій простішою та швидшою.

Однією з причин, чому вони, ймовірно, хотіли зберегти поле коду як можна меншим, щоб воно не штрафувало інструкції типу J. Як ви, напевно, знаєте, в інструкціях типу J використовується псевдо-пряма адресація. На користь тому, хто грає вдома, я коротко поясню це.

Поле адреси інструкції типу J становить 26 біт. Оскільки вказівки завжди вирівнюються в 4 байтах, вам не потрібно зберігати щонайменше два значущі біти, а це означає, що ви фактично маєте 28 біт адреси. Однак адресний простір у MIPS I становить 32 біти. Тож чотири чотири біта місця стрибка взяті з лічильника програми.

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

lui $r,target >> 16
    ori $r,$r,target & 0xFFFF
    jr $r

Сьогодні це не так вже й погано, але в 1985 році це багато циклів годин.

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