Как эффективно разработать код операции для процессора?


12

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

спасибо заранее


1
Сначала соберите свой ALU, и посмотрите, какие провода управления ему нужны. Затем подключите их напрямую к регистру «текущей инструкции». То же самое для логики управления доступом к памяти и любых других основных классов кодов операций. Затем используйте оставшиеся биты, чтобы выбрать, какая подсхема активирована.
user253751

1
Существует также оригинальная статья Кена Чепмена о его 8-битной программируемой машине состояний KCPSM, также известной как PicoBlaze. Он описывает, как он выбрал инструкции и разработал ISA. dc.uba.ar/materias/disfpga/2010/c2/descargas/…
Пеббельс

Ответы:


9

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

Малым будет MSP430 от TI, это 16-битный процессор с 22 инструкциями.

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

Вы также можете посмотреть на AVR Atmel, они также имеют довольно небольшой набор инструкций.

В своем небольшом проекте я попытался разработать простой 32-битный процессор на VHDL с небольшим набором команд (14 инструкций):

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

Из-за моего текущего свободного времени это не полностью закончено. Инструкции выполнены, но две не проверены и, возможно, некоторые флаги состояния отсутствуют.


Но я не нашел что-то, где я мог бы увидеть, что такое настоящая кодировка и почему она была выбрана именно так.
Benjoyo

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

7

Изучите (но не повторяйте) подход ARM к кодированию команд. Он сильно ориентирован на префиксы (как подход дерева Хаффмана, рекомендованный Дзардой) и очень однороден с точки зрения того, где регистр выбирает часть инструкции.

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


Я не совсем понимаю, что вы имеете в виду под контрольными сигналами.
Benjoyo

Что я нашел в ARM и что мне нравится, так это поле условия, я включу его.
Benjoyo

Управляющие сигналы являются входами для различных мультиплексоров и позволяют передавать данные между частями ЦП.
pjc50

Для 16-битной архитектуры я не думаю, что кодировка инструкций ARM является подходящей. Mayby thumb2 лучше. Но мне нравится способ кодирования MIPS, простой и легкий для понимания, хотя и немного расточительный
phuclv

4

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

Случайные вещи, чтобы искать

  • Деревья Хаффмана
  • Фиксированная длина или переменная кодировка?
  • Это дизайн фон Неймана с единым адресным пространством или гарвардский стиль с отдельными данными / программой?

Отличное видео на Computerphile о деревьях Хаффмана:

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


Кодирование Хаффмана не подойдет для кодирования фиксированной длины, верно?
Benjoyo

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

Но я не понимаю, какую оптимизацию это приносит. Это не помогает мне с дизайном схемы. Какова цель при использовании кодирования Хаффмана для кода операции?
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

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

3

Одна вещь, которую вы должны рассмотреть, - разрешить ли любую форму инструкции из нескольких слов или что-нибудь, что может «действовать» как инструкция из нескольких слов; если вы это сделаете, вы можете подумать, следует ли использовать дополнительные слова инструкции после основной инструкции или префиксные слова перед ней. Разрешение префиксов и последующих слов может увеличить сложность обработки прерываний, но это может избежать необходимости размещать редко используемые инструкции в том же пространстве кода операции, что и обычно используемые.

Если инструкции извлекаются в цикле до их выполнения, можно получить инструкцию «условного перехода», которая либо заставит пропустить следующее слово инструкции, либо его содержимое будет перенесено непосредственно в счетчик программ; такой дизайн может добавить некоторую дополнительную сложность к последовательности прерываний, но это может облегчить необходимость использования большой части пространства кода операции для команд "ветвление", "переход" и "вызов", в то же время позволяя гораздо более широкий диапазон условий ветвления чем было бы возможно в противном случае. Поскольку ветвь, которая берется, обычно требует мертвого цикла после выполнения самой инструкции, независимо от того, откуда исходит адрес, получение адреса из следующего слова, которое было выбрано, но не будет выполнено, не требует дополнительных затрат. время.

Несмотря на то, что перемещение целевого адреса из инструкций ветвления сократит объем занимаемого ими кода операции, 16-разрядный формат кода операции все еще довольно узок. Использование префиксных инструкций может помочь в этом. Если, например, нужно иметь 32 регистра, для того чтобы любой регистр мог быть независимо указан как source1, source2 и destination, потребуется 15 битов в коде операции, что дает колоссальную сумму двух команд. Не очень полезно. С другой стороны, было бы неплохо использовать любой из 32 регистров для каждого из трех операндов. Можно сбалансировать две цели, если любая операция ALU, которой не предшествует префикс, использует восемь битов, чтобы сделать два выбора из одного из шестнадцати регистров, но имеет операцию ALU, которая следует сразу за префиксом, используя некоторые биты в префиксе вдоль с восьмым из следующей инструкции, чтобы позволить независимый выбор обоих источников и адресатов из полного набора из 32. Инструкции, которые используют верхние регистры, будут занимать два слова / цикла, а не одно, но в некоторых случаях такой компромисс может быть целесообразным. Самая большая трудность с использованием префиксов заключается в том, что необходимо либо предотвратить возникновение прерывания между префиксом и следующей инструкцией, либо обеспечить, чтобы в случае возникновения прерывания команда после префикса все еще использовала правильные регистры [например, имея программу -counter save logic хранит адрес последней выполненной не префиксной инструкции]. но в некоторых случаях такой компромисс может быть оправдан. Самая большая трудность с использованием префиксов заключается в том, что необходимо либо предотвратить возникновение прерывания между префиксом и следующей инструкцией, либо обеспечить, чтобы в случае возникновения прерывания команда после префикса все еще использовала правильные регистры [например, имея программу -counter save logic хранит адрес последней выполненной не префиксной инструкции]. но в некоторых случаях такой компромисс может быть оправдан. Самая большая трудность с использованием префиксов заключается в том, что необходимо либо предотвратить возникновение прерывания между префиксом и следующей инструкцией, либо обеспечить, чтобы в случае возникновения прерывания команда после префикса все еще использовала правильные регистры [например, имея программу -counter save logic хранит адрес последней выполненной не префиксной инструкции].

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


0

Этот парень лучше всех разбирается в жесткой проводке жестко закодированной части декодера, которая объясняет управляющие линии для жестко запрограммированного процессора: http://minnie.tuhs.org/CompArch/Tutes/week03.html Как вы можете видеть, ваш Выбор в кодах операций действительно влияет на сложность логики декодирования.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.