Timmy 1 20 мая, 2015 Опубликовано 20 мая, 2015 · Жалоба Есть немного странный вопрос, если коротко зачем процессору регистры? У меня есть очень длинное объяснение откуда возник этот вопрос, но его никто не прочтет. Потому кому не трудно напишите что особенного вы видите в регистрах, в сравнении например с РАМ. А там тему можно будет и развить. Регистры - это вообще-то тоже РАМ, причём в хард процессорах они обычно делаются на такой же матрице, что и большая SRAM. В процессоре регистры отличаются короткой прямой адресацией, быстрым доступом без необходимости кэширования, локальностью(нет необходимости их синхронизировать в многоядерной системе). Хотя локальная РАМ в многоядерных DSP тоже бывает. Для эффективного хранения регистров в BRAM используется конвейер, типа вот такого. Там рабочие копии регистров гуляют по быстрым защёлкам на границах ступеней конвейера ID/EX/MEM/WB, а за синхронностью рабочих копий и общей матрицы(которая на ступени ID) следит Forwarding Unit. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 20 мая, 2015 Опубликовано 20 мая, 2015 · Жалоба ну то есть надо на самом деле сделать 3 портовую оболочку брам, даже чуть проще 2 порта чтения и один запись, и автоматом получиться огромный регистровый файл. А вот теперь вопрос, зачем регистры в таком решении отделять от РАМ проца? Выигрыш только в сокращении шины адресации? В регистрах на LUTах можно за один такт складывать любые 2 и писать в третий, но эта возможность порождает дикие мультиплексоры которые жрут все LUTы, альтернативой я так понимаю служит несколько тактовая операция R1+R2->R3, реализуемая через 3 портовую БРАМ. И в этом случае у меня получается что нет смысла делать отдельно БРАМ регистров, и включить его в общий РАМ проца. Правильно рассуждаю или я что-то не учел? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ynicky 0 20 мая, 2015 Опубликовано 20 мая, 2015 (изменено) · Жалоба ну то есть надо на самом деле сделать 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 21 мая, 2015 Опубликовано 21 мая, 2015 · Жалоба не понял расчета) у меня тогда получается 4 такта. 2 такта на чтение операндов и 1 такт на исполнение, 1 такт на запись. Почему вы в такты включили размер команды? Или почему вы в RISC процессоре исключили загрузку команды? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ynicky 0 21 мая, 2015 Опубликовано 21 мая, 2015 (изменено) · Жалоба не понял расчета) у меня тогда получается 4 такта. 2 такта на чтение операндов и 1 такт на исполнение, 1 такт на запись. Почему вы в такты включили размер команды? Или почему вы в RISC процессоре исключили загрузку команды? А где 4 такта на извлечение команды? Если, конечно, Вы не сделаете извлечение 4 слов команды за 1 такт. Иначе нарушается конвейер при выполнении каждой команды за 1 такт. Я уже не говорю о том, что команды обработки данных перемежаются с командами ветвления. Хотя это справедливо и для тех RISC, где каждая команда имеет длину в 1 слово. Изменено 21 мая, 2015 пользователем Ynicky Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 21 мая, 2015 Опубликовано 21 мая, 2015 · Жалоба Ну РИСКу тоже надо извлекать команду как не крути, так что им один такт тоже надо добавить. Потом код операции размером в слово - очень много, нафига столько команд. То есть остаются адреса, если память длинная, то они большие, это верно. 1. извлекаем адрес 1 операнда 2. Задаем адрес 1 операнда на РАМ, читаем адрес 2 операнда 3. Читаем 1 операнд, выставляем адрес 2 операнда, извлекаем код операции 4. Читаем второй операнд, извлекаем адрес результата 5. Обрабатываем команду, выставляем адрес результата 6. Сохраняем результат. Команду даже можно в 2 такта выполнять, на 4 и 5. . А я хочу пойти дальше ограничить адреса 256 значениями и словной адресацией, и сделать 32 битную команду с 8 битным кодом операции, тогда получаем за 1 такт все адреса и команды, читаем их, выполняем, сохраняем. Но в целом я понял в чем смысл отделения регистров в особую группу, основное - сокращение поля адресов в команде. Спасибо народ! %) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 21 мая, 2015 Опубликовано 21 мая, 2015 · Жалоба Команду даже можно в 2 такта выполнять, на 4 и 5. . А я хочу пойти дальше ограничить адреса 256 значениями и словной адресацией, и сделать 32 битную команду с 8 битным кодом операции, тогда получаем за 1 такт все адреса и команды, читаем их, выполняем, сохраняем. Ну если достаточно 256 слов памяти, почему бы и нет. Можно предусмотреть и команды доступа к "большой" памяти с непосредственным смещением 8-10 бит(2 бита откусить от кода операции), OpenRISC с этим как-то живёт:). А как вы будете кодировать команды с непосредственным операндом? Их, правда, можно сделать двухадресными, а не трёхадресными, как в MIPS, тогда появятся 16 свободных бит под непосредственный операнд. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
krux 8 21 мая, 2015 Опубликовано 21 мая, 2015 · Жалоба забыли ещё про регистр-адрес текущей выполняемой инструкции. если его тоже в озу хранить, то добавляйте такты на его чтение, а также при условных/безусловных переходах такты на его запись и чтение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 21 мая, 2015 Опубликовано 21 мая, 2015 · Жалоба А как вы будете кодировать команды с непосредственным операндом? планировал его вторым словом после команды. Что-то аля Thumb2, то есть там 16 бит команда, но если надо 32. У меня будет 32 бита - стандарт, если надо 64. Память команд будет с 64 шиной чтения, то есть после задания счетчика команд будет доступно сразу 2 слова, на случай если понадобиться операнд (таких случаев будет на самом деле 90%) в работе проца. Счетчика команд, как и контрольный регистр - это будут 2 единственных регистра сделанных в ядре на ЛУТах. Счетчик команд будет жестко посажен на шину памяти команд, как адрес. Как то так планировал. Мне и РАМ то по хорошему не нужна, для того что делаю, больше нужны всякие РОНы, но надо чтобы ядро все луты не сожрало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pavia 0 22 августа, 2015 Опубликовано 22 августа, 2015 (изменено) · Жалоба Есть такой вопрос. Наверное на него легко найти ответ. Но что-то я не нашёл. Процессор без портов в/в это не процессор. Собственно вопрос как их организовать? Наверно где-то есть статья для зелёных новичков, но что-то я не заметил. С примерами на Virelog. Изучая схему IBM AT компьютеров там наглядно показана работа с портами. Но всё таки такой вопрос как принято это делать у плисоводов? Обязательно ли в процессоре должен быть блок УУ(устройство управления, анг Control unit) который осуществляет выбор функции по #CS (chip select) В IBM AT было всего 6 основных чипов по 16 портов каждый. А вот в IBM PS/2 уже более "оптимально" каждый чип мог иметь произвольное число портов. Поэтому располагались они плотнее. Отсюда вопрос какие есть инструменты для автоматического генерирования дешифратора адреса? Ещё можно включить проверку адреса в сами функции, как это сделано в PIIX когда перешли с шины ISA на LPC. PS. Наверно мне надо ещё что-то прочитать про мультиплексоры. Изменено 22 августа, 2015 пользователем Pavia Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 22 августа, 2015 Опубликовано 22 августа, 2015 · Жалоба Есть такой вопрос. Наверное на него легко найти ответ. Но что-то я не нашёл. Процессор без портов в/в это не процессор. Собственно вопрос как их организовать? Наверно где-то есть статья для зелёных новичков, но что-то я не заметил. С примерами на Virelog. PS. Наверно мне надо ещё что-то прочитать про мультиплексоры. Странные выкладки приводят к еще более странным результатам... Процессоры " без портов в/в" живут себе вполне прилично... Просто Вы не умеете их готовить. Примеров - полно на opencores... "статья для зелёных новичков" - хотя бы у меня на сайте... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pavia 0 22 августа, 2015 Опубликовано 22 августа, 2015 · Жалоба Странные выкладки приводят к еще более странным результатам... Процессоры " без портов в/в" живут себе вполне прилично... Просто Вы не умеете их готовить. Примеров - полно на opencores... "статья для зелёных новичков" - хотя бы у меня на сайте... А как тогда процессоры без портов получаю данные и выдают их в мир? Они же должны как-то взаимодействовать с окружающим миром. По поводу ваших статей, так я их читал и перечитал. Но так и не нашёл где в них можно прочитать про дерево дешифровки адреса... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 22 августа, 2015 Опубликовано 22 августа, 2015 · Жалоба А как тогда процессоры без портов получаю данные и выдают их в мир? Они же должны как-то взаимодействовать с окружающим миром. По поводу ваших статей, так я их читал и перечитал. Но так и не нашёл где в них можно прочитать про дерево дешифровки адреса... Там есть статья о битовом процессоре. Это процессор, который работает как "память - память"... И к памяти добавлен блок ДМА, который сам циклически копирует содержимое этой памяти во внешние устройства ввода-вывода... А портов как таковых у процессора может и не быть. Например DEC или по нашему Электроника-60 не имела отдельных команд для ввода-вывода. Они располагались в общем поле памяти... А интеловская система придумана для сокращения дешифратора адресов и упрощения узла контроля... Если в статьях что-то не понятно, то могу по скайпу словами рассказать.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
agregat 0 23 августа, 2015 Опубликовано 23 августа, 2015 · Жалоба Документ, тут на стр.14 показана реализация портов ввода вывода Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pavia 0 23 августа, 2015 Опубликовано 23 августа, 2015 (изменено) · Жалоба Мой вопрос касался "5.10 Control bus encoder" стр 13. Спасибо, не совсем то, что я ожидал увидеть. Но ответ я понял, надо рисовать схему. Изменено 23 августа, 2015 пользователем Pavia Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться