эртайп лучше знают и помнят потому, что даже в одном эртайповском уровне намного больше разнообразия (в игровом процессе тоже, не только в графике), чем во всех зинапсовских вместе взятых

КОМУ проще? Аппаратчику, который будет разводить проц — да, проще; и у производителя, возможно, будет чуть меньше брака. Программисту — нет, ничуть не проще, ему нах не нужно думать про этот бит. Программист вовсе не мечтает забивать голову мусорной инфой про формат опкода и из-за удобства разводки и копеечной разницы в цене потерять в удобстве программирования. Так вот я и спрашиваю поэтому — «комп мечты» КОГО ты хочешь изобрести?

R-Type не зацепил. Графика хорошА была, но перемещение по знакоместам даже в детстве жутко выбешивало. Zynaps игрался в разы плавнее, да и вышел на год раньше. Так что кто еще папа))) «Движок» у зинапса технологичнее и обидно, блин, что массы только эртайп знают =)

вы что не понимаете, что один заранее готовый бит на блюдечке это гораздо гораздо проще, чем микропрограммы с декодером по таблицам и так далее? что за бред?

простоты ЧЕГО? «комп мечты» железячника или программиста? их мечты часто вступают в противоречие

да просто для простоты. нет тут никаких микропрограмм — вся логика прямолинейна и однообразна.

а зачем вообще в опкод пихать такой флаг? опкод считай просто индекс для декодера, который вытащит из таблицы полную формулу команды/микропрограммы в общем виде со всеми флагами, где что муксить

Бит TI это прямой флаг для декордера инструкции нужно подгатавливать для АЛУ аргумент Y или нет. Всего инструкций 32, половина из них с зажжённым битом TI — половина нет. Но действительно бит TI уходит в АЛУ вместе с INSTR выступая как полный 5-битовый код инструкцуии, т.к. двухоперандные и однооперандные инструкции с одинаковым полем INSTR могут делать совершенно разные вещи.

рукалицо.жпг

ну, а здесь-то почему не судьба применить отдельную ОПЕРАЦИЮ инкремента на число, закодированнное в опкоде??

вместо того, чтобы сокращать количество доступных операций еще в два раза))))))

ты уж определись — либо у тебя бит TI определяет что-то отдельно, а само ДЕЙСТВИЕ, производимое в АЛУ с операндами, кодируется битами INSTR и тогда у тебя возможно, повторяю, ЛИШЬ 16 УНИКАЛЬНЫХ ОПЕРАЦИЙ АЛУ; либо у тебя 32 разных действия кодируются 5 битами, но тогда нет фактически никакого отдельного TI, просто нет

P.S.
Появился большой искус еще 1 бит поля INSTR откусить под «режим адресации immediate», когда поле SRC есть immediate-данное от 0 до 7, а TI — его знак. Тогда не нужны будут отдельные inc/dec 2/3/4/5/6/7, но надо подумать.

Так их и есть 32, бит TI просто для простоты определяет какие из них однооперандные, а какие — двухоперандные. Они не обязаны быть одинаковыми, это просто удобство для декодера.

в том, что ты на ровном месте потерял до половины нумерации для инструкций
у тебя сейчас возможно лишь 16 различных instr, а могло быть 32-(x<16)

а я пояснил, что тратить целый бит опкода на то не нужно
во всех случаях «существенного отличия» экономнее использовать другой instr

Эм… Так и есть. Просто по одному биту кода инструкции можно тут же понять нужен Y на входе или нет.
А в чём проблема то?

а я пояснил, что тратить целый бит опкода на то не нужно
во всех случаях «существенного отличия» экономнее использовать другой instr

вроде как [DST] читать не нужно только для load

Я только что выше подробнее пояснил.

Заполнение Y реально может быть не просто ненужным, но и времязатратным процессом.

вроде как [DST] читать не нужно только для load, что определяется по опкоду (лучше нулевому) и без TI
и второй раз в операциях типа [DST=SRC],[SRC=DST] — ну так там уже прочитано в первый раз

Я сильно над этим не задумывался еще, но т.к. есть 16 однооперандных инструкций (и они никак не обязаны быть теми же что и 16 двухоперандных), то возможно там будет и dec/inc-1/2/3/4 и возможно что-то еще.

лично я между любым кол-вом дополнительных инкрементов и обменом всегда выберу обмен
уже только ради одного обмена со стековым указателем, даже если больше не понадобится никак 8)

P.S.
Вообще однооперандные инструкции это такие в которых X пропускаясь через АЛУ перед записью в Y никак не зависит от Y.
Т.е. (используется синтаксис операторов похожий на синтаксис Си-подобных языков):
R0 = R1; move
R0 =+1 R1; inc1
R0 =<< R2; сдвиг влево на 1 бит
R0 =+2 R3; inc2
R0 ~= R4; побитовая инверсия
и так далее. т.е. над SRC производится операция и записывается в DST

Двухоперандные инструкции берут и SRC и DST и пропустив их оба через АЛУ записывают результат в DST:

R0 += R1; сумма R0 и R1 записывается в R0
R0 <<= R2; R0 сдвигается влево на R2 бит (существенное отличие с однооперандным аналогом!)
R0 cmp R3; R0 и R3 сравниваются — неизменность R0 достигается за счёт того, что АЛУ именно его (Y) выдаёт на выходе
и так далее.

это можно делать одновременно, и TI не нужен
если не понадобится Y, так не понадобится

Одновременно считывать из памяти не получится. Заполнение Y реально может быть не просто ненужным, но и времязатратным процессом.

(кстати, у тебя какой порядок слов-байтов? little/big endian?)

А тут это исключительно как захочет программист. Ячейка памяти 16-битная, регистры — 16-битные, если нужно компоновать 32-битные, то это пользовательский код целиком.

то inc1+inc2 ничем не лучше add3

Я сильно над этим не задумывался еще, но т.к. есть 16 однооперандных инструкций (и они никак не обязаны быть теми же что и 16 двухоперандных), то возможно там будет и dec/inc-1/2/3/4 и возможно что-то еще.

Если TI=1, то общая схема инструкции следующая:
1. SRC загружается в X
2. DST загружается в Y

это можно делать одновременно, и TI не нужен
если не понадобится Y, так не понадобится

Так и есть — это пожалуй единственная «бесполезная» комбинация аргументов которая осталась и действительно сделать её каким то особым случаем выглядит привлекательно.
Но лично мне не нравится, что ломается общая схема работы Simpleton-а.

почему ломается? считай просто, что схема общая у тебя такая:
1) может быть, записать PC в стек
2) DST ?= SRC
и нет проблем :D

Ну зависит от задачи. Например, если первый элемент нам подходит — переходим к его хвосту, а если нет — пропускаем до следующего элемента.

это только если по первому слову ясно (кстати, у тебя какой порядок слов-байтов? little/big endian?)
но если нужно элемент проверить целиком и условно пропустить следующий, то inc1+inc2 ничем не лучше add3