tarasv> Впрочем ИБМ аплодирует тебе стоя. Ты пытаешься продать ИБМ Stretch как процессор общего назначения в 2024м.
Нет.
Соотвественно, все рассуждения о том, как был плох Stretch и как
поэтому (sic!) неверны мои предложения теряют почву.
tarasv> Давай посмотрим где на самом деле безумие.
Вот давай.
tarasv> Только не надо тащить сюда тот темный лес который получился у Интел при сохранении аппаратной совместимости по адресации памяти с 8битными предшественниками и бинарной совместимости сначала при переходе с 16бит на 32, а потом на 64. Новый дизайн с чистого листа.
Интересно, что ты сразу, сходу отметаешь главное наследие ИБМ (и ЕС), ради которого убили свою разработку - CISC. И да, тут ты отметаешь именно CISC как принцип, а не его конкретную реализацию.
tarasv> Байтовая архитектура, шина и регистры 64бита. OPcode 8/16/32/64 требует 2 бита на флаги размерности операнда, на OPCODE остается 6бит... То что ты модификатор размерности записал как псевдо операнд команды ничего не меняет, у тебя будет 64 команды ADD вместо 4х в х86.
И сразу ошибка - в чём?
В том, что ты пытаешься взять худшее из обоих миров, при этом выкинув всё ценное. Разумеется, результат не катит.
Ещё и ещё раз: байтовая (ну или какая там?) арифметика НЕ НУЖНА. Да, ей пользуются время от времени потому, что в нынешних процах нет
нормальных способов работать с данными малого размера, но это от горя, а горе - от инерции мышления. Которая уже после многих постов так и не даёт даже воспринять, казалось бы, однозначно изложенное моё предложение.
Я предлагаю оставить только одно -
load/store операции с произвольным размером данных, возможно даже не 2, а 4 опкода (с арифметическим дополнением старших бит и без). Только и всего. Возможно (если мы говорим о конкретно 60-х и бизнес-машинах) то с командой векторных операций (а не бесконечно плодащиеся SIMD с опять же фиксированным размером данных, как случилось в нашей реальности!) а-ля rep mov, repe stosb, etc в х86, широко применяемых и по сей день.
Вся арифметика (сравнения, логика, и т.п.) производится пословно, в самых обычных для машины данной размерности операциях. Это и есть
естественный путь развития, расширения естественной для любой машины пословной адресации и обработки на данные меньшей размерности.
Если ты аккуратно повспоминаешь применение байтовой (допустим) арифметики на х86, то ты с удивлением обнаружишь, что собссно,
байтовость арифметики не используется почти нигде, а в большинстве случаев переполнение с переносом - по сути ошибка, особая ситуация. Исключения же -
крайне редки, и по сути являются хаком. "Программирование через хак" - не самая хорошая практика, тем более, что с нормальной пословной арифметикой эти хаки в большинстве своём становятся не нужны. В тех реально редких случаях, когда тебе действительно нужно определять переполнение - сделай проверку на старшие биты, операция store же субсловного размера из словного регистра при необходимости сгенерит исключение (как и другая арифметическая операция; потому что store в меньший размер по факту и является арифметической операцией даункаста).
То есть, ещё раз и не оставляя неоднозначностей: произвольного размера
только загрузка. Обработка же идёт как обычно - пословно.
Само собой, в любой вменяемой аппаратной реализации доступ к данным субсловного размера идёт через через защёлку, то есть, каждый раз никто не делает выборку того же самого слова для извлечения оттуда новой порции данных.
Смещение - суть индекс в векторной операции, это всегда и везде регистр, потому как в 99.99% случаев переменная. Для исключений с выборкой по конкретному индексу (нулевому) прогрузить регистр нулём нет беды.
Поэтому вместо 64 MOV (а потом ADD, а потом SUB, а потом CMP, а потом ещё чего-там-надо), которые видятся тебе, у меня 2 (или 4) "байтовые" (в частном случае) команды всего. Против твоего учетверения всего набора команд в твоём гипотетическом RISC или сложном выборе типа операнда у IBM/360 с безумным расходом кодового пространства. Байтовые загрузки в байтовые регистры. Раз байтовые загрузки в байтовые регистры - значит байтовая арифметика с байтовыми регистрами, так? И понеслось! И ради чего?
Можешь объяснить?
Чем фентезийный код типа
mov rax, byte[adr]
mov rbx, byte[adr2]
cmp rax, rbx
хуже реального специализированного(!)
mov al, byte[adr]
mov ah, byte[adr2]
cmp al, ah
А ведь в большинстве машин "работа с байтами"© подразумевает именно такой подход.
Далее - а посмотри на реальную работу со строками. У тебя всё равно есть загрузка базы, у тебя всё равно есть загрузка индекса (а если ты или компилятор используете векторные команды на x86, у вас и альтернатив нет; а не использовать их глупо: rep movdw быстрее любой альтернативы), что ты экономишь?
Одну команду загрузку регистра размером? регистр, в котором хранится размер?
Ещё что-то?
Ты только что просрал 75% кодового пространства, замутил огромный сложный декодер, обустроил замудрённые коммутаторы на регистровом файле и АЛУ ради этой "экономии"?
И это ли не безумие? Офигеть.
Посмотри на альтернативу. Оставляем везде только слова. Оставляем загрузку произвольного поля по адресу, индексу и размеру. Добавляем к этому векторизацию, не префиксом, а командой повторения rep R (делать следующую команду пока (--R)!=0). Вся работа с байтами остаётся такой же или лучше, чем у ИБМ, но в дополнение получаешь...