В 3х-уровневом конвейере получится, тк запись результата идет не в память, а в регистр аккумулятора.
А латентность результата будет 2..3 такта (зависит от того, откуда брать результат - с выхода АЛУ, или с регистра аккумулятора).
В первом такте команды по одному порту считывается один байт новой команды, а по другому порту в это время идет доступ к регистру или константе предыдущей команды.
В следующем такте по другому порту считывается регистр или константа, а по первому - следующая команда.
В третьем такте результат записывается в аккумулятор, и идет чтение операндов следующей команды.
Все сходится, тк запись в память идет отдельной командой, и есть запас в тактах.

Сообщение отредактировал Leka - Nov 5 2015, 11:39

Это уже несколько иная федерация по вольной борьбе, что-то я уже сомневаюсь в желаемом результате в 200 ЛЕ...

200 ЛЕ - это с запасом. 3х-уровневый конвейер естественным образом получается, без дополнительных элементов.
1 уровень - внутренние регистры одного порта памяти, 2 уровень - внутренние регистры другого порта памяти, 3 уровень - регистр аккумулятора.

Если интересно, и устраивает система команд - могу детально проработать и проверить практически.

Система команд, и это чувствуется, продумана и хорошо смотрится для 8-разрядника, везде видно влияние 86-архитектуры, а может, и AVR... Узкое место - это общая память, можно было бы её и разделить на RAM и ROM (что-то из гарвардского стиля) , но тогда не будет возможности модификации программы самой программой, но насколько это необходимо... Еще, память может быть очень большой, и как туда с программами на ассемблере, только на С, но это уже другой уровень усилий по разработке всей системы вместе с программной оболочкой.
С конвейерами программ еще не работал, где можно почитать о правильных методах их построения? Ясно, что конвейер надо приостанавливать на входе когда в нем длинные команды, например STM Ra, а также очищать на условиях... Хотел бы сделать такой процессор сам, потом сравнить, если получится меньше 200ЛЕ, то это будет экстра класс, т.к. мой miniByte-2 занял многовато места, хотя для мелких приложений у него есть и свои преимущества...

Гарвардскую архитектуру придумали для скорости, использование ее для 8-битника - не имеет смысла. Если нужна скорость - лучше сразу отказаться от 8-разрядного АЛУ. Назвали "miniByte" - логично ограничить минимумом число ЛЕ и блоков памяти, и выжать максимум быстродействия при этих условиях. 8-разрядные команды будут выгодно (в идеологическом плане) отличать такой проц от AVR/PicoBlaze/LatticeMico8/etc. А потом сразу перейти на "maxiLong" ...

Сообщение отредактировал Leka - Nov 6 2015, 09:10

Советую все-таки делать 16-разрядное АЛУ, пусть и с 8-разрядными командами (ориентир на 200 ЛЕ остается в силе). 8-разрядные АЛУ не дают никаких преимуществ в ЛЕ из-за более сложной схемы адресации.

Сообщение отредактировал Leka - Nov 9 2015, 10:04

Кто-нибудь может помочь мне с LCC ?
Попробую разобраться, но это потребует времени... Хотелось бы сначала взглянуть на ассемблерный код, генерируемый LCC для аккумуляторной архитектуры, чтобы понять, стоит ли изучать...

Так вроде LCC изначально пример кодогенератора для x86 в 32-бит варианте содержал? Это та что надо архитектура?

Нет, х86, это не аккумуляторная архитектура, а регистровая.
Аккумуляторная, когда операции АЛУ меняют только один аккумулятор,
и R1=R1+R2 выльется в: A=R1, A=A+R2, R1=A.

По поводу аккумуляторной архитектуры своих софт процессоров, пока для теоретического обсуждения и без привязки к какому-то процессору.
Предлагаю отказаться от аккумулятора и назначать в РОН-ах текущий аккумулятор. Для этого в PSW (слово состояния программы) иметь поле [] для задания номера текущего аккумулятора, а результат всех аккумуляторных операций направлять в соответствующий РОН по этому номеру. И тогда, например, R1=R1+R2 выльется в: PSW[]=номер R1, A=A+R2.

Простите что вклиниваюсь, в процессорной архитектуре я чайник. Но можете хотя бы в общих словах сказать, чем плох, к примеру, популярный в прошлом R3000 (архитектура MIPS-1) в качестве софт процессора?
Нам нужен софт процессор в проект, но самодельное мы не можем себе позволить, будем брать что то из классики.

Плох только тем, что места займёт больше, чем восьмибитный. А так все фирменные софтпроцессоры большой тройки - NIOS2,Microblaze,Mico32 представляют собой испорченный разными способами MIPS.

Сообщение отредактировал Timmy - Nov 12 2015, 08:25

Спасибо, понял.
Еще вопрос. Конвейерный R3000 иногда вынужден останавливаться, если текущая команда использует результат предыдущей (еще не записанной в регфайл или память). Есть какие то простенькие, но конвейерные вариации MIPS, где процессор не останавливается?

Как можно не останавливаться, если операнд команды ещё не определён? Хотя можно попробовать выполнить следующую команду, но внеочередное исполнение команд - это уже не слишком простенькая вариация. К тому же бесполезная, так как лучше расставлять команды в правильном порядке при компиляции.

Аккумулятор физически расположен вне РОН, иначе это будет регистровая архитектура. В чисто аккумуляторной архитектуре операции АЛУ меняют только аккумулятор. Те это load-store архитектура по отношению как к памяти, так и к РОН.