[Timmy 1]

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

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

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

[Golikov 0]

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

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

 

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

 

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

 

 

[Ynicky 0]

ну то есть надо на самом деле сделать 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 адреса источников).

 

Изменено 20 мая, 2015 пользователем Ynicky

[Golikov 0]

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

 

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

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

 

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

[Ynicky 0]

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

 

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

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

 

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

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

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

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

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

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

Изменено 21 мая, 2015 пользователем Ynicky

[Golikov 0]

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

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

 

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

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

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

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

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

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

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

 

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

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

 

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

 

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

[Timmy 1]

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

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

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

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

[krux 8]

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

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

[Golikov 0]

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

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

 

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

 

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

 

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

[Pavia 0]

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

 

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

 

 

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

 

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

 

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

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

 

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

 

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

 

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

Изменено 22 августа, 2015 пользователем Pavia

[iosifk 3]

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

 

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

 

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

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

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

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

 

 

[Pavia 0]

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

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

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

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

 

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

[iosifk 3]

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

 

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

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

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

 

[agregat 0]

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

[Pavia 0]

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

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

Изменено 23 августа, 2015 пользователем Pavia