Свои процессоры, Разработка своих процессоров со своей системой команд Опции

[Timmy]

Есть немного странный вопрос, если коротко зачем процессору регистры? У меня есть очень длинное объяснение откуда возник этот вопрос, но его никто не прочтет.
Потому кому не трудно напишите что особенного вы видите в регистрах, в сравнении например с РАМ. А там тему можно будет и развить.

Регистры - это вообще-то тоже РАМ, причём в хард процессорах они обычно делаются на такой же матрице, что и большая SRAM. В процессоре регистры отличаются короткой прямой адресацией, быстрым доступом без необходимости кэширования, локальностью(нет необходимости их синхронизировать в многоядерной системе). Хотя локальная РАМ в многоядерных DSP тоже бывает. Для эффективного хранения регистров в BRAM используется конвейер, типа вот такого. Там рабочие копии регистров гуляют по быстрым защёлкам на границах ступеней конвейера ID/EX/MEM/WB, а за синхронностью рабочих копий и общей матрицы(которая на ступени ID) следит Forwarding Unit.

[Golikov A.]

ну то есть надо на самом деле сделать 3 портовую оболочку брам, даже чуть проще 2 порта чтения и один запись, и автоматом получиться огромный регистровый файл.
А вот теперь вопрос, зачем регистры в таком решении отделять от РАМ проца? Выигрыш только в сокращении шины адресации?

В регистрах на LUTах можно за один такт складывать любые 2 и писать в третий, но эта возможность порождает дикие мультиплексоры которые жрут все LUTы, альтернативой я так понимаю служит несколько тактовая операция R1+R2->R3, реализуемая через 3 портовую БРАМ.

И в этом случае у меня получается что нет смысла делать отдельно БРАМ регистров, и включить его в общий РАМ проца. Правильно рассуждаю или я что-то не учел?

[Ynicky]

ну то есть надо на самом деле сделать 3 портовую оболочку брам, даже чуть проще 2 порта чтения и один запись, и автоматом получиться огромный регистровый файл.
А вот теперь вопрос, зачем регистры в таком решении отделять от РАМ проца? Выигрыш только в сокращении шины адресации?

В регистрах на LUTах можно за один такт складывать любые 2 и писать в третий, но эта возможность порождает дикие мультиплексоры которые жрут все LUTы, альтернативой я так понимаю служит несколько тактовая операция R1+R2->R3, реализуемая через 3 портовую БРАМ.

И в этом случае у меня получается что нет смысла делать отдельно БРАМ регистров, и включить его в общий РАМ проца. Правильно рассуждаю или я что-то не учел?

Давайте порассуждаем.
Команда в Вашем случае должна содержать:
Опкод - 1 слово.
Адрес первого операнда - 1 слово.
Адрес второго операнда - 1 слово.
Адрес приемника - 1 слово.
+ 2 такта минимум на чтение операндов.
+ 1 такт на исполнение в АЛУ.
+ 1 такт запись результата.
Итого получили 8 тактов.

В RISC процессоре:
2 такта на загрузку первого операнда.
2 такта на загрузку второго операнда.
1 такт на исполнение в АЛУ.
1 такт на запись результата.
Итого получили 6 тактов.

В Вашем случае можно сэкономить 1 такт начиная считывать первый операнд
не дождавшись конца загрузки команды.
Можно еще укоротить адреса операндов (например в одном слове 2 адреса источников).


Сообщение отредактировал Ynicky - May 20 2015, 17:19

[Golikov A.]

не понял расчета)

у меня тогда получается 4 такта.
2 такта на чтение операндов и 1 такт на исполнение, 1 такт на запись.

Почему вы в такты включили размер команды? Или почему вы в RISC процессоре исключили загрузку команды?

[Ynicky]

не понял расчета)

у меня тогда получается 4 такта.
2 такта на чтение операндов и 1 такт на исполнение, 1 такт на запись.

Почему вы в такты включили размер команды? Или почему вы в RISC процессоре исключили загрузку команды?

А где 4 такта на извлечение команды?
Если, конечно, Вы не сделаете извлечение 4 слов команды за 1 такт.
Иначе нарушается конвейер при выполнении каждой команды за 1 такт.
Я уже не говорю о том, что команды обработки данных перемежаются с командами ветвления.
Хотя это справедливо и для тех RISC, где каждая команда имеет длину в 1 слово.

Сообщение отредактировал Ynicky - May 21 2015, 06:32

[Golikov A.]

Ну РИСКу тоже надо извлекать команду как не крути, так что им один такт тоже надо добавить.
Потом код операции размером в слово - очень много, нафига столько команд.

То есть остаются адреса, если память длинная, то они большие, это верно.
1. извлекаем адрес 1 операнда
2. Задаем адрес 1 операнда на РАМ, читаем адрес 2 операнда
3. Читаем 1 операнд, выставляем адрес 2 операнда, извлекаем код операции
4. Читаем второй операнд, извлекаем адрес результата
5. Обрабатываем команду, выставляем адрес результата
6. Сохраняем результат.

Команду даже можно в 2 такта выполнять, на 4 и 5. .
А я хочу пойти дальше ограничить адреса 256 значениями и словной адресацией, и сделать 32 битную команду с 8 битным кодом операции, тогда получаем за 1 такт все адреса и команды, читаем их, выполняем, сохраняем.

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

Спасибо народ! %)

[Timmy]

Команду даже можно в 2 такта выполнять, на 4 и 5. .
А я хочу пойти дальше ограничить адреса 256 значениями и словной адресацией, и сделать 32 битную команду с 8 битным кодом операции, тогда получаем за 1 такт все адреса и команды, читаем их, выполняем, сохраняем.

Ну если достаточно 256 слов памяти, почему бы и нет. Можно предусмотреть и команды доступа к "большой" памяти с непосредственным смещением 8-10 бит(2 бита откусить от кода операции), OpenRISC с этим как-то живёт.
А как вы будете кодировать команды с непосредственным операндом? Их, правда, можно сделать двухадресными, а не трёхадресными, как в MIPS, тогда появятся 16 свободных бит под непосредственный операнд.

[krux]

забыли ещё про регистр-адрес текущей выполняемой инструкции.
если его тоже в озу хранить, то добавляйте такты на его чтение, а также при условных/безусловных переходах такты на его запись и чтение.

[Golikov A.]

А как вы будете кодировать команды с непосредственным операндом?

планировал его вторым словом после команды. Что-то аля Thumb2, то есть там 16 бит команда, но если надо 32. У меня будет 32 бита - стандарт, если надо 64.

Память команд будет с 64 шиной чтения, то есть после задания счетчика команд будет доступно сразу 2 слова, на случай если понадобиться операнд (таких случаев будет на самом деле 90%) в работе проца.

Счетчика команд, как и контрольный регистр - это будут 2 единственных регистра сделанных в ядре на ЛУТах. Счетчик команд будет жестко посажен на шину памяти команд, как адрес.

Как то так планировал. Мне и РАМ то по хорошему не нужна, для того что делаю, больше нужны всякие РОНы, но надо чтобы ядро все луты не сожрало.

[Pavia]

Есть такой вопрос. Наверное на него легко найти ответ. Но что-то я не нашёл.

Процессор без портов в/в это не процессор. Собственно вопрос как их организовать? Наверно где-то есть статья для зелёных новичков, но что-то я не заметил. С примерами на Virelog.


Изучая схему IBM AT компьютеров там наглядно показана работа с портами. Но всё таки такой вопрос как принято это делать у плисоводов?

Обязательно ли в процессоре должен быть блок УУ(устройство управления, анг Control unit) который осуществляет выбор функции по #CS (chip select)

В IBM AT было всего 6 основных чипов по 16 портов каждый.
А вот в IBM PS/2 уже более "оптимально" каждый чип мог иметь произвольное число портов. Поэтому располагались они плотнее.

Отсюда вопрос какие есть инструменты для автоматического генерирования дешифратора адреса?

Ещё можно включить проверку адреса в сами функции, как это сделано в PIIX когда перешли с шины ISA на LPC.

PS. Наверно мне надо ещё что-то прочитать про мультиплексоры.

Сообщение отредактировал Pavia - Aug 22 2015, 17:42

[iosifk]

Есть такой вопрос. Наверное на него легко найти ответ. Но что-то я не нашёл.

Процессор без портов в/в это не процессор. Собственно вопрос как их организовать? Наверно где-то есть статья для зелёных новичков, но что-то я не заметил. С примерами на Virelog.

PS. Наверно мне надо ещё что-то прочитать про мультиплексоры.

Странные выкладки приводят к еще более странным результатам...
Процессоры " без портов в/в" живут себе вполне прилично... Просто Вы не умеете их готовить. Примеров - полно на opencores...
"статья для зелёных новичков" - хотя бы у меня на сайте...

[Pavia]

Странные выкладки приводят к еще более странным результатам...
Процессоры " без портов в/в" живут себе вполне прилично... Просто Вы не умеете их готовить. Примеров - полно на opencores...
"статья для зелёных новичков" - хотя бы у меня на сайте...

А как тогда процессоры без портов получаю данные и выдают их в мир? Они же должны как-то взаимодействовать с окружающим миром.

По поводу ваших статей, так я их читал и перечитал. Но так и не нашёл где в них можно прочитать про дерево дешифровки адреса...

[iosifk]

А как тогда процессоры без портов получаю данные и выдают их в мир? Они же должны как-то взаимодействовать с окружающим миром.

По поводу ваших статей, так я их читал и перечитал. Но так и не нашёл где в них можно прочитать про дерево дешифровки адреса...

Там есть статья о битовом процессоре. Это процессор, который работает как "память - память"... И к памяти добавлен блок ДМА, который сам циклически копирует содержимое этой памяти во внешние устройства ввода-вывода... А портов как таковых у процессора может и не быть. Например DEC или по нашему Электроника-60 не имела отдельных команд для ввода-вывода. Они располагались в общем поле памяти... А интеловская система придумана для сокращения дешифратора адресов и упрощения узла контроля...
Если в статьях что-то не понятно, то могу по скайпу словами рассказать..

[agregat]

Документ, тут на стр.14 показана реализация портов ввода вывода

[Pavia]

Мой вопрос касался "5.10 Control bus encoder" стр 13.
Спасибо, не совсем то, что я ожидал увидеть. Но ответ я понял, надо рисовать схему.

Сообщение отредактировал Pavia - Aug 23 2015, 07:28