Придумай инструкцию x86!

Едва ли обычный код даст ответ на этот вопрос. Например, пару дней назад я заметил, что у меня лишние mul`ы и div`ы во фрагменте который выполняется ну наверно миллиарды раз. Их можно было вынести за пределы цикла, что я и сделал. Уж раньше, это точно были довольно "тяжёлые" команды. Ессно, я предвкушал многого . До изменений, код выполнялся 76 сек. А после изменений - ... 75. Первая мысль: "ну нифига себе интел оптимизировал свои аппаратные умножители/делители. mul и div стали почти незаметны на фоне других команд и перестали тормозить код???" Оно кстати, может быть во многом и так, но через несколько минут я вспомнил, что все мои множители умещаются в 12-13 бит. Не всегда, но часто один из множителей может иметь лишь 2-4, ну 5 единиц. И именно единицы "работают", не нули. Короче этот мой конкретный случай, не сильно годится для окончательных выводов. Нужны грамотные, серьёзные исследования, но кто этим станет заниматься?

 

Eсли говорить жёстко об архитектуре x86, то местами этот CISC попахивает недо-CISC.

Возмём прификс «REP», который костылём служит лишь для узкого набора инструкций (CMPS/LODS/MOVS/SCAS/STOS/INS/OUTS) и абсолютно бесполезен для остальных инструкций…
Как пример с потолка:

• Что мешало сделать «REP CBW» для конвертации массива Байтов в массив Слов (REP MOVS WORD PTR[EDI],BYTE PTR[ESI])?
• Что мешало сделать «REP CWD» для конвертации массива Слов в массив Двойных Слов (REP MOVS DWORD PTR[EDI],WORD PTR[ESI])?
  
• Что мешало сделать «REP XLAT» для перекодировки целого массива (REP XLAT [EDI],[EBX])?
• Что мешало сделать «REP AAA» для сложения двух массивов (REP ADD [EDI],[ESI])?
  
• Что мешало сделать «REP AAD» для деления двух массивов (REP DIV [EDI],[ESI])?
  
• Что мешало сделать «REP AAM» для перемножения двух массивов (REP MUL [EDI],[ESI])?
  
• Что мешало сделать «REP AAS» для вычитания двух массивов (REP SUB [EDI],[ESI])?
  
• Что мешало вместо отдельных RCL/RCR/ROL/ROR/SAL/SAR/SHL/SHR просто указывать счётчик префиком («REP SHL AL,1» --> «SHL AL,CL»)?
  
• Что мешало ввести операцию программной задержки на n тактов (REP NOP)?

Я понимаю, что это местами могло бы внести путаницу и усложнило бы архитектуру. Но, усложнение в рамках CISC - закономерность, а не исключение.
Тем более, расширение поля взаимодействия префикса REP сделало бы систему команд более гибкой и ортогональной.
К тому же, в сочетании с префиксом LOCK все указанные выше операции с массивами (REP CBW/XLAT/AAA и т.п.) обеспечили бы бо́льшую производительность и безопасность на ранних этапах развития архитектуры.

И есть ещё одно наблюдение отсутствия архитектур, где в специальных операциях Сложения и Вычитания признак переноса распространялся бы ещё и в направлении от старшего к младшему.
Так, если операцию RCL AL,1 можно заменить на ADC AL,AL, то операцию RCR заменить нечем. В этом случае операция Сложения с обратным распространением Переноса могла бы это сделать…
В этом случае спокойно можно упразднить целую группу циклического сдвига RCL/RCR/ROL/ROR/SHL/SHR, так как Зеркальное Сложение более гибкое…

P.S.: Это всё рассуждения на тему Симулятора MMX…

 

А я бы убрал REP вообще. Хотя LOOP 2-байта, но может "съедаться" конвеером (замерял некоторые случаи, за всегда не скажу) и тем более
до $-126/$+129 ! А изменения индексов это скорее свойства самих команд, а не префикса.

 

Нa счёт этого имеется тоже лихая идея: Организовать связку инструкций «REP CALL»…
Такой экзотикой мы могли бы явно сообщить конвейеру, что код по адресу от CALL необходимо максимально оптимизировать/компилировать, чтобы тот работал уже как макроинструкция.
Естественно нельзя в этом «REP CALL» ссылаться на код, объём которого превышает некоторые формальные пределы конвейера (например, расчёт преобразований Фурье обязан уместиться)…

То есть, убираем LOOP, но вводим «REP CALL Macros». Тогда RET будет следить за перезапуск кода, пока ECX не ноль…

P.S.: В этом плане инженерам можно было двигаться, ИМХО, чем протаптывать тот же критикуемый узкоспециализированный AVX-512…

 

Особенные инструкции внедряют исходя из их полезности.
Полезность всех этих REP XLAT или REP CWD околонулевая плюс большие вопросы как именно они должны работать и что именно и как инкрементировать и на сколько.
Вот некий LOOP который бы одновременно уменьшал бы ebx и увеличивал esi и edi и проходил бы дальше если ebx сравнялся с нулём был бы простым и в то же время подходящим к множеству шаблонов сокращённых циклов альтернативой.
Только нужно было бы два минимум варианта инструкции для байтов и слов и да, её еще нужен байт offset-а перехода.
Но тут именно не ecx, а ebx, потому что только с bx исторически в i8086 можно было складывать в адресациях.
При этом условии можно было бы фигачить на i8086 сокращённые циклы такого толка:

Код (Text):

1.  
2. @loop: mov ax, [bx+si]
3. add [bx+di], ax
4. bxloopw @loop ; обязательно через суффикс w/b указываем, что именно со словами работаем или с байтами
5.  

Это было бы сокращённым аналогом REP ADD из выше, но требовало бы добавления всего одной особенной инструкции в систему команд чтобы охватить довольно широкий спектр.

 

Ветвлeния, на сколько я понимаю, со всякими предсказаниями - намного затратнее, чем префикс. Тот же Z80 мог читать машинную инструкцию в комбинации до двух префиксов.
В идеале ветвлений должно быть минимум: CMOVcc ввели относительно поздно.

Нельзя ли было тот же REP-префикс расширить до REPD для префиксирования уже двух (Double) инструкций?
То есть, вместо «REP MOVSB» можно было бы использовать «REPD LODSB STOSB», а вот «REPD LODSB STOSW» здесь мог бы как «REP CBW» - конвертировать массив байтов в слова.

P.S.: Иногда так и хочется перетряхнуть всю архитектуру и на её основе разработать аналогичный концепт…
Например, обычный «ADD AL,[BX+SI+1]» записывать префиксно «PTR [BX+SI] ;; ADD AL,1 », как в Z80…

 

Конечно bxloop из примера выше больше, чем rep movs и в разы - шесть байт на код выше против двух у rep movs. В три раза. Но на i8086 это могло бы помочь экономить байты и циклы. А вот на i386 уже слабее - там кодировка [bx+si] еще два байта сожрёт. Суть просто в том, что экзотические команды делающие странные мало нужные вещи невыгодно усложняют процессор, но одна лишь особенная bxloop позволила бы экономить байты и циклы в довольно многих и очень разных местах поэтому и выглядит привлекательно.
Вообще Intel не позволили префиксам REP "прохлаждаться" и активно их сейчас используют в массе инструкций: https://wasm.in/threads/principy-ko...x86-64-ili-exal-prefiks-cherez-prefiks.34390/

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

 

По мне - множество различных загрузок микрокода с быстрым переключениям между уже загруженными отдать пользователю.
Процессор - это лишь набор микрокоманд. Реализация уровней привелегий под вопросом.