Leka 0 5 ноября, 2015 Опубликовано 5 ноября, 2015 (изменено) · Жалоба В 3х-уровневом конвейере получится, тк запись результата идет не в память, а в регистр аккумулятора. А латентность результата будет 2..3 такта (зависит от того, откуда брать результат - с выхода АЛУ, или с регистра аккумулятора). В первом такте команды по одному порту считывается один байт новой команды, а по другому порту в это время идет доступ к регистру или константе предыдущей команды. В следующем такте по другому порту считывается регистр или константа, а по первому - следующая команда. В третьем такте результат записывается в аккумулятор, и идет чтение операндов следующей команды. Все сходится, тк запись в память идет отдельной командой, и есть запас в тактах. Изменено 5 ноября, 2015 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Serhiy_UA 1 5 ноября, 2015 Опубликовано 5 ноября, 2015 · Жалоба В 3х-уровневом конвейере получится... Это уже несколько иная федерация по вольной борьбе, что-то я уже сомневаюсь в желаемом результате в 200 ЛЕ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 5 ноября, 2015 Опубликовано 5 ноября, 2015 · Жалоба 200 ЛЕ - это с запасом. 3х-уровневый конвейер естественным образом получается, без дополнительных элементов. 1 уровень - внутренние регистры одного порта памяти, 2 уровень - внутренние регистры другого порта памяти, 3 уровень - регистр аккумулятора. Если интересно, и устраивает система команд - могу детально проработать и проверить практически. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Serhiy_UA 1 5 ноября, 2015 Опубликовано 5 ноября, 2015 · Жалоба Если интересно, и устраивает система команд - могу детально проработать и проверить практически. Система команд, и это чувствуется, продумана и хорошо смотрится для 8-разрядника, везде видно влияние 86-архитектуры, а может, и AVR... Узкое место - это общая память, можно было бы её и разделить на RAM и ROM (что-то из гарвардского стиля) , но тогда не будет возможности модификации программы самой программой, но насколько это необходимо... Еще, память может быть очень большой, и как туда с программами на ассемблере, только на С, но это уже другой уровень усилий по разработке всей системы вместе с программной оболочкой. С конвейерами программ еще не работал, где можно почитать о правильных методах их построения? Ясно, что конвейер надо приостанавливать на входе когда в нем длинные команды, например STM Ra, а также очищать на условиях... Хотел бы сделать такой процессор сам, потом сравнить, если получится меньше 200ЛЕ, то это будет экстра класс, т.к. мой miniByte-2 занял многовато места, хотя для мелких приложений у него есть и свои преимущества... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 6 ноября, 2015 Опубликовано 6 ноября, 2015 (изменено) · Жалоба Гарвардскую архитектуру придумали для скорости, использование ее для 8-битника - не имеет смысла. Если нужна скорость - лучше сразу отказаться от 8-разрядного АЛУ. Назвали "miniByte" - логично ограничить минимумом число ЛЕ и блоков памяти, и выжать максимум быстродействия при этих условиях. 8-разрядные команды будут выгодно (в идеологическом плане) отличать такой проц от AVR/PicoBlaze/LatticeMico8/etc. А потом сразу перейти на "maxiLong" ... Изменено 6 ноября, 2015 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2015 Опубликовано 9 ноября, 2015 (изменено) · Жалоба ...Хотел бы сделать такой процессор сам, потом сравнить, если получится меньше 200ЛЕ, то это будет экстра класс, т.к. мой miniByte-2 занял многовато места, хотя для мелких приложений у него есть и свои преимущества... Советую все-таки делать 16-разрядное АЛУ, пусть и с 8-разрядными командами (ориентир на 200 ЛЕ остается в силе). 8-разрядные АЛУ не дают никаких преимуществ в ЛЕ из-за более сложной схемы адресации. Изменено 9 ноября, 2015 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2015 Опубликовано 9 ноября, 2015 · Жалоба Кто-нибудь может помочь мне с LCC ? Попробую разобраться, но это потребует времени... Хотелось бы сначала взглянуть на ассемблерный код, генерируемый LCC для аккумуляторной архитектуры, чтобы понять, стоит ли изучать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 9 ноября, 2015 Опубликовано 9 ноября, 2015 · Жалоба Так вроде LCC изначально пример кодогенератора для x86 в 32-бит варианте содержал? Это та что надо архитектура? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 9 ноября, 2015 Опубликовано 9 ноября, 2015 · Жалоба Нет, х86, это не аккумуляторная архитектура, а регистровая. Аккумуляторная, когда операции АЛУ меняют только один аккумулятор, и R1=R1+R2 выльется в: A=R1, A=A+R2, R1=A. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Serhiy_UA 1 12 ноября, 2015 Опубликовано 12 ноября, 2015 · Жалоба Нет, х86, это не аккумуляторная архитектура, а регистровая. Аккумуляторная, когда операции АЛУ меняют только один аккумулятор, и R1=R1+R2 выльется в: A=R1, A=A+R2, R1=A. По поводу аккумуляторной архитектуры своих софт процессоров, пока для теоретического обсуждения и без привязки к какому-то процессору. Предлагаю отказаться от аккумулятора и назначать в РОН-ах текущий аккумулятор. Для этого в PSW (слово состояния программы) иметь поле [] для задания номера текущего аккумулятора, а результат всех аккумуляторных операций направлять в соответствующий РОН по этому номеру. И тогда, например, R1=R1+R2 выльется в: PSW[]=номер R1, A=A+R2. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 12 ноября, 2015 Опубликовано 12 ноября, 2015 · Жалоба Простите что вклиниваюсь, в процессорной архитектуре я чайник. Но можете хотя бы в общих словах сказать, чем плох, к примеру, популярный в прошлом R3000 (архитектура MIPS-1) в качестве софт процессора? Нам нужен софт процессор в проект, но самодельное мы не можем себе позволить, будем брать что то из классики. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 12 ноября, 2015 Опубликовано 12 ноября, 2015 (изменено) · Жалоба Простите что вклиниваюсь, в процессорной архитектуре я чайник. Но можете хотя бы в общих словах сказать, чем плох, к примеру, популярный в прошлом R3000 (архитектура MIPS-1) в качестве софт процессора? Нам нужен софт процессор в проект, но самодельное мы не можем себе позволить, будем брать что то из классики. Плох только тем, что места займёт больше, чем восьмибитный. А так все фирменные софтпроцессоры большой тройки - NIOS2,Microblaze,Mico32 представляют собой испорченный разными способами MIPS. Изменено 12 ноября, 2015 пользователем Timmy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 12 ноября, 2015 Опубликовано 12 ноября, 2015 · Жалоба Спасибо, понял. Еще вопрос. Конвейерный R3000 иногда вынужден останавливаться, если текущая команда использует результат предыдущей (еще не записанной в регфайл или память). Есть какие то простенькие, но конвейерные вариации MIPS, где процессор не останавливается? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 12 ноября, 2015 Опубликовано 12 ноября, 2015 · Жалоба Спасибо, понял. Еще вопрос. Конвейерный R3000 иногда вынужден останавливаться, если текущая команда использует результат предыдущей (еще не записанной в регфайл или память). Есть какие то простенькие, но конвейерные вариации MIPS, где процессор не останавливается? Как можно не останавливаться, если операнд команды ещё не определён? Хотя можно попробовать выполнить следующую команду, но внеочередное исполнение команд - это уже не слишком простенькая вариация. К тому же бесполезная, так как лучше расставлять команды в правильном порядке при компиляции:). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 12 ноября, 2015 Опубликовано 12 ноября, 2015 · Жалоба По поводу аккумуляторной архитектуры своих софт процессоров, пока для теоретического обсуждения и без привязки к какому-то процессору. Предлагаю отказаться от аккумулятора и назначать в РОН-ах текущий аккумулятор. Для этого в PSW (слово состояния программы) иметь поле [] для задания номера текущего аккумулятора, а результат всех аккумуляторных операций направлять в соответствующий РОН по этому номеру. И тогда, например, R1=R1+R2 выльется в: PSW[]=номер R1, A=A+R2. Аккумулятор физически расположен вне РОН, иначе это будет регистровая архитектура. В чисто аккумуляторной архитектуре операции АЛУ меняют только аккумулятор. Те это load-store архитектура по отношению как к памяти, так и к РОН. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
