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

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



<font size=1>З.Ы. Это прежде все тренеровка творческого мышления в улучшении существующей архитектуры, но возможно лучшие инструкции будут реализованы в реальных камнях (или накрайняк эмуляторе).</font><!--size-->

 

Может добавить команды перехода при IF=1 и IF=0.

 

Реверса хочется 0x12345678(до)-->0x87654321(после), тоже для бит, насколько это сложно будет реализовать архитектурно?



з.ы. можно подсмотреть ф-ции из других архитектур + у Уоррена часть есть (nlz и т.д.)

 

у AMD в процессоры Athlon64+ уже встроен контроллер памяти, так что неплохо иметь набор инструкций прямого управления им - например копирование памяти по линейкам без участия кэша.



Очень хороший потенциал есть в архитектуре Itanium. В качестве развития можно представить префиксы условного выполнения, которые пускай и используют устройство branch но сокращали бы размер кода:

Код (Text):

1.  
2. cmp rax, -1
3. oneq   add rax,rax  ;;  
4.  

эквивалентно

Код (Text):

1.  
2. cmp rax, -1
3. jne @f
4. add  rax, rax
5. @@:
6.  

 

bogrus

Думаю просто - за счет Alu, не сложнее во всяком случае инструкции not. Например использовать внутренний регистр с дополнительной инверсной шиной считывания.

 

по поводу реверса



alpet

спорно

но суть не в этом.



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

множество алгоритмов типа БПФ заработают эффективнее. фильтры, кодеки медиа заиграют по-новому. добро победит!

 

alpet

В асме для GBA тоже такая фигня есть. Только там, как я понимаю, без префиксов, непосредственно в опкоде указание на выполнение при условии. Т.е. инструкции вроде ldrZ.

 

Вот если бы строковые инструкции работали нормально...

 

Кстати согласен с Loger'ом.

До каких пор интересно будет продолжаться идиотизм с rep stosd и тому подобными вещами. Эти инструкции были придуманы СПЕЦИАЛЬНО для строковых операций и быстрого копирования памяти. И что? Используются извратные оптимизации типа:



mov esi, [src] // source array

mov edi, [dst] // destination array

mov ecx, [len] // number of QWORDS (8 bytes)

shr ecx, 1 // convert to 16-byte size count

// (assumes len / 16 is an integer)

copyloop:

mov eax, dword ptr [esi]

mov dword ptr [edi], eax

mov ebx, dword ptr [esi+4]

mov dword ptr [edi+4], ebx

mov eax, dword ptr [esi+8]

mov dword ptr [edi+8], eax

mov ebx, dword ptr [esi+12]

mov dword ptr [edi+12], ebx

add esi, 16

add edi, 16

dec ecx

jnz copyloop

 

_hidden_

Они и действуют быстрее на малых блоках, а как правило строки всегда не очень длинные. Сделать их более универсальными по быстродействию врядли получится.



Вот еще новая инструкция - маскирующее сравнение:

cmpm src1, src2

Алгоритм:

nflags = cmp src1, src2

and eflags,nflags



Будет очень полезная для оптимизации подобного кода:

if (a == 1 && b == 3 && c == 4)

Результат работы cl.exe (MS C++ Compiler 13.10.3077):

cmp dword ptr [a],1

jne main+71h (401081h)

xor ecx,ecx

cmp dword ptr ,3

sete cl

xor edx,edx

cmp dword ptr [c],4

sete dl

and ecx,edx

je main+71h (401081h)

... some code on TRUE

С использованием cmpm:

cmp dword ptr [a], 1 ;; zf = (a == 1)

cmpm dword ptr , 3 ;; zf &= (b == 3)

cmpm dword ptr [c], 4 ;; zf &= (c == 4)

jne main+69h (401079h)



По идее с такой инструкцией сильно сокращается и размер кода и в случае компилятора расход регистров.

 

alpet

> Они и действуют быстрее на малых блоках

Не понял, кто "они" и что значит "малые" ?



rep movsd работает быстро при выравненых адресах на "достаточно больших" блоках. И тесты это подтверждают (см. копирование памяти).

А для "строчек" из 10-20 символов и оптимизировать ИМХО нечего.

 

alpet

По-моему самодельный rep scas\movs\lods\stos будет быстрее оригинального на любых строках, иногда в 4 раза (недавно обсуждали в топе)

 

leo

Бывает и есть чего - например поиск по строковым записям в не индексированных базах данных, копирование больших таблиц. Впрочем это не по теме треда.

 

я выдумывать бы чего то навороченного не стал

вот что бы понадобилось бы действительно



abs reg/[...] - думаю это понятно

add reg1,reg2,reg3 - по принципу трехоперандового imul



давно хотел команду чтобы управлять округлением fpu без шаманства с флагами.



а по поводу rep movsd

посмотрите memcpy(...) и ужаснитесь

 

bogrus

> "самодельный rep scas\movs\lods\stos будет быстрее оригинального на любых строках"



Не надо валить все строковые операции в одну кучу (тем более для "любых" длин).

В P6 и P4 rep stosd и rep movsd аппаратно ускорены для больших выравненных блоков с "существенно" различающимися адресами (запись идет целыми линейками через write-combining буферы).

А.Фог в pentopt.pdf (раздел 18.4 String Instructions) приводит условия, при соблюдении которых обе эти операции обеспечивают на P6 скорость порядка 5байт/цикл ("что почти в 3 раза больше, чем когда эти условия не соблюдаются").

 

leo

Виноват, согласен, при соблюдении условий обгоняет

 

Единственное что в строковых операциях не удобно - привязка к определенным регистрам. В большинстве случаев трех и двух операндное управление дало бы лучшие результаты:



repnz movsd eax, edx, [count] ;; in,out reg32, in,out reg32, in mem32.

 

_hidden_

add reg1,reg2,reg3 - по принципу трехоперандного imul

А чем lea reg1,[reg2+reg3] не устраивает?

 

устраивает

стормозил



а вот организовать бы что нибудь типа

mov eax,dx:ax

mov rax,edx:eax

 

mov eax,dx:ax - shl eax,16 + shrd eax,edx,16, хотя это уже менее изящно

mov rax,edx:eax - не понял?