Як ефективно спроектувати опкод для процесора?


12

Я будую простий 16-бітний процесор у Logisim і маю готовий ALU і ті коди, які я хочу мати. Тепер мені дуже важко знайти правильне кодування для команд, щоб різним підсхемам (наприклад, логіці, арифметиці) не потрібні всі контрольні дроти (що створюють кодування) як вхідні дані, але якнайменше. Чи є якісь стратегії чи методи, які допомагають ефективно розробити опкод?

THX заздалегідь


1
Спочатку побудуйте свій ALU і подивіться, які контрольні дроти йому потрібні. Потім підключіть їх безпосередньо до реєстру "поточної інструкції". Те саме для логіки управління доступом до пам'яті та будь-яких інших основних класів опкодів. Потім використовуйте будь-які біти, що залишилися, щоб вибрати, яка підсхема активована.
користувач253751

1
Існує також оригінальний документ від Кена Чапмана з його 8-бітного програмованого державного машинного апарату KCPSM aka PicoBlaze. Тут описано, як він обирає інструкції та розробляє ISA. dc.uba.ar/materias/disfpga/2010/c2/descargas/…
Paebbels

Відповіді:


9

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

Невеликим буде MSP430 від TI, це 16-бітовий процесор з приблизно 22 інструкціями.

http://www.physics.mcmaster.ca/phys3b06/MSP430/MSP430_Instruction_Set_Summary.pdf

Ви також можете заглянути в відеореєстратори Atmel, вони також мають невеликий набір інструкцій.

У своєму невеликому проекті я спробував розробити простий 32-бітний процесор в VHDL з невеликим набором інструкцій (14 інструкцій):

http://www.blog-tm.de/?p=80

Через мій теперішній вільний час він не повністю закінчений. Інструкції реалізовані, але дві не перевірені, і, можливо, деякі прапори стану відсутні.


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

Ви можете знайти кодування Actuall в репортажі : github.com/TM90/MISC_Processor/raw/master/Documentation/… . Причиною я вибираю ці кодування таким чином, що логіка в інструкції декодера отримана мінімальною.
TM90

7

Вивчіть (але не повторюйте) підхід ARM до кодування інструкцій. Це сильно орієнтована на префікси (як підхід до дерева Хаффмана, рекомендований Дзардою) і дуже рівномірна з точки зору того, де реєстр вибирає частину інструкції.

Ненадумливий, але надійний підхід полягає в перерахуванні всіх наявних у вас керуючих сигналів , які, ймовірно, будуть перевищувати 16 біт, а потім спробувати зробити мінімізацію логіки стилю Карно-карти на них.


Я не розумію, що ви маєте на увазі під керуючими сигналами.
Бенджойо

Що я знайшов і подобається в ARM - це стан стану, я його включатиму.
Беньойо

Сигнали керування - це входи в різні мультиплексори і дозволяють прямі дані між частинами процесора.
pjc50

Для 16-бітної архітектури я не думаю, що кодування інструкцій ARM є доцільним. Mayby thumb2 краще. Але мені подобається спосіб кодування MIPS, простий і зрозумілий, хоча трохи марнотратний
phuclv

4

Одного разу я спробував зробити 4-розрядний процесор з 8-розрядним ядром довжини інструкцій в Logisim. Нарешті, він справді доповнив просту машину, більше ніж процесор.

Випадкові речі, які потрібно шукати

  • Дерева Хаффмана
  • Кодування з фіксованою довжиною або змінною?
  • Це дизайн фон Неймана з єдиним адресним простором або в гарвардському стилі з окремими даними / програмою?

Відмінне відео на комп’ютерфілі про дерева Хаффмана:

https://www.youtube.com/watch?v=umTbivyJoiI


Хаффман кодування не працює для кодування з фіксованою довжиною, правда?
Бенджойо

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

Але я не розумію, яку оптимізацію це приносить. Це не допомагає мені з схемою дизайну. Яка мета при використанні кодування Хаффмана для опкоду?
Беньойо

4

У ISA, який я писав для класу, колись був 4-бітний оп-код: 1XXX ALU instructions 01XX jump, jump register, call etc 001X branch not equal, branch equal zero 000X 0 - load, 1 - store

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


Цей вид оптимізації - це те, що я шукаю на даний момент. Але у мене є 5-бітний опкод, і я борюся з групуванням команд разом, щоб це мало сенс у ланцюзі.
Беньойо

@Benjoyo ви можете мати ще багато інструкцій ALU з верхнім набором біт. Також покриття мого стрибка було досить слабким, і більшість звичайних гілок потребували б двох інструкцій. Взагалі я вважав такі категорії як: Математика / Контроль / Пам'ять

3

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

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

Навіть незважаючи на те, що переміщення цільової адреси з інструкцій гілки зменшить кількість простору коду, який вони збивають, 16-бітний формат коду все ще досить щільний. Використання інструкцій з префіксами може допомогти у цьому. Якщо, наприклад, потрібно мати 32 регістри, що дозволяє будь-якому реєстру незалежно вказати джерело1, джерело2 та призначення, зажадає 15 біт в коді, що дозволяє отримати цілих дві інструкції. Не дуже корисно. З іншого боку, було б добре використовувати будь-який з 32 регістрів для кожного з трьох операндів. Можна врівноважити дві цілі, виконавши будь-яку операцію ALU, якій не передує префікс, використовувати вісім біт, щоб зробити два вибірки одного з-шістнадцяти регістрів, але операцію ALU, яка негайно слідує за префіксом, використовує деякі біти в префіксі уздовж з восьми з наступної інструкції, щоб дозволити незалежний вибір обох джерел та місця призначення з повного набору 32. Інструкції, які використовують верхні регістри, потребують двох слів / циклів, а не одного, але в деяких випадках такий компроміс може бути корисним. Найбільша складність у використанні префіксів полягає в тому, що потрібно або запобігти виникненню переривання між префіксом та наступною інструкцією, або іншим чином переконатися, що якщо в ній відбувається переривання, інструкція після префікса все-таки використовуватиме правильні регістри [наприклад, за допомогою програми -counter save logic зберігає адресу останньої виконаної інструкції без префікса]. але в деяких випадках такий компроміс може бути корисним. Найбільша складність із використанням префіксів полягає в тому, що потрібно або запобігти виникненню переривання між префіксом та наступною інструкцією, або іншим чином переконатися, що якщо перерва виникає там, інструкція після префікса все-таки використовуватиме правильні регістри [наприклад, за допомогою програми -counter save logic зберігає адресу останньої виконаної інструкції без префікса]. але в деяких випадках такий компроміс може бути корисним. Найбільша складність із використанням префіксів полягає в тому, що потрібно або запобігти виникненню переривання між префіксом та наступною інструкцією, або іншим чином переконатися, що якщо перерва виникає там, інструкція після префікса все-таки використовуватиме правильні регістри [наприклад, за допомогою програми -counter save logic зберігає адресу останньої виконаної інструкції без префікса].

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


0

Цей хлопець має найкращі деталі щодо розуміння жорсткої проводки жорстко кодованої частини Декодера, яка пояснює контрольні лінії для жорстко кодованого процесора: http://minnie.tuhs.org/CompArch/Tutes/week03.html Як бачите, ваш Вибір у Opcodes дійсно впливає на те, наскільки складна логіка декодування.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.