Jump to content

    

Свои процессоры

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

Потому кому не трудно напишите что особенного вы видите в регистрах, в сравнении например с РАМ. А там тему можно будет и развить.

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

Share this post


Link to post
Share on other sites

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

А вот теперь вопрос, зачем регистры в таком решении отделять от РАМ проца? Выигрыш только в сокращении шины адресации?

 

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

 

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

 

 

Share this post


Link to post
Share on other sites
ну то есть надо на самом деле сделать 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 адреса источников).

 

Edited by Ynicky

Share this post


Link to post
Share on other sites

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

 

у меня тогда получается 4 такта.

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

 

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

Share this post


Link to post
Share on other sites
не понял расчета)

 

у меня тогда получается 4 такта.

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

 

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

А где 4 такта на извлечение команды?

Если, конечно, Вы не сделаете извлечение 4 слов команды за 1 такт.

Иначе нарушается конвейер при выполнении каждой команды за 1 такт.

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

Хотя это справедливо и для тех RISC, где каждая команда имеет длину в 1 слово.

Edited by Ynicky

Share this post


Link to post
Share on other sites

Ну РИСКу тоже надо извлекать команду как не крути, так что им один такт тоже надо добавить.

Потом код операции размером в слово - очень много, нафига столько команд.

 

То есть остаются адреса, если память длинная, то они большие, это верно.

1. извлекаем адрес 1 операнда

2. Задаем адрес 1 операнда на РАМ, читаем адрес 2 операнда

3. Читаем 1 операнд, выставляем адрес 2 операнда, извлекаем код операции

4. Читаем второй операнд, извлекаем адрес результата

5. Обрабатываем команду, выставляем адрес результата

6. Сохраняем результат.

 

Команду даже можно в 2 такта выполнять, на 4 и 5. .

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

 

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

 

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

Share this post


Link to post
Share on other sites
Команду даже можно в 2 такта выполнять, на 4 и 5. .

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

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

А как вы будете кодировать команды с непосредственным операндом? Их, правда, можно сделать двухадресными, а не трёхадресными, как в MIPS, тогда появятся 16 свободных бит под непосредственный операнд.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
А как вы будете кодировать команды с непосредственным операндом?

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

 

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

 

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

 

В IBM AT было всего 6 основных чипов по 16 портов каждый.

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

 

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

 

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

 

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

Edited by Pavia

Share this post


Link to post
Share on other sites
Есть такой вопрос. Наверное на него легко найти ответ. Но что-то я не нашёл.

 

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

 

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

Странные выкладки приводят к еще более странным результатам...

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

"статья для зелёных новичков" - хотя бы у меня на сайте...

 

 

Share this post


Link to post
Share on other sites
Странные выкладки приводят к еще более странным результатам...

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

"статья для зелёных новичков" - хотя бы у меня на сайте...

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

 

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

Share this post


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

 

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

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

Если в статьях что-то не понятно, то могу по скайпу словами рассказать..

 

Share this post


Link to post
Share on other sites

Мой вопрос касался "5.10 Control bus encoder" стр 13.

Спасибо, не совсем то, что я ожидал увидеть. Но ответ я понял, надо рисовать схему.

Edited by Pavia

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this