[x86] Kilka instrukcji na jednym opkodzie.

Pisze sobie disassembler kodu dla 8086 który będzie służył mi do emulatora. Generalnie troche działa, dekodowanie bajtu ModRM/prefixów/itd jest łatwe. Ale. Czy ktoś mądry może wyjaśnić mi, dlaczego przykładowo
or i cx (za wykluczeniem or/cx ax dla akumulatora są dedykowane opki) mają te same opkody?
Objdump jakoś to łyka i wyświetla poprawnie. Przykład
objdump -M intel -m i8086 -D -b binary test.bin

 
   3:   90                   nop
   4:   83 cb 17             or     bx,0x17
   7:   83 e1 20             and    cx,0x20
   a:   83 fa 0c             cmp    dx,0xc
   d:   80 f3 17             xor    bl,0x17
  10:   80 37 17             xor    BYTE PTR [bx],0x17
  13:   f7 eb                imul   bx
  15:   f7 f0                div    ax
  17:   90                   nop

Z tego co rozumiem, weźmy na przykład instrukcję or bx, 0x17, bajt 0x83 to opkod, 0xcb to ModRM w którym znajdują sie rejestr źródłowy(3 bity), docelowy(3 bity), i selektor(2 bity) instrukcji, no i 0x17 to wartość.
Ad ModRM ładna tabelka.
No i generalnie tu jest mój problem, jak rozkodować czy to or, and czy cmp (czy jescze co innego, sporo instrukcji jest na jednym opkodzie, lista tu )
Może ktoś coś takiego pisał, i miał podobny problem, bądź po prostu - wie ;-)
Żeby nie było że nie szukam, zrobiłem wstępny research stacka i:
Tu gosciu wspomina to, co wiem, ale nic o tych opkodach.
No generalnie na razie nie zajrzałem w miejsce w które powinienem zajrzeć najpierw, manual od 8086, dosyć trudny w odbiorze ;p
Ok, teraz ide chyba jednak zajrzeć w manual, tam pewno coś będzie. Anyway thx z góry za odpowiedzi.

Zajrzeć do manuala i tabel instrukcji. Zgodnie z twoją logiką myślenia lista instrukcji zaczynałaby się na 0x00 a kończyła na 0xFF. W budowie instrukcji pełno jest wyjątków i sytuacji (np. sposób kodowania instrukcji wykorzystujących wskaźnik stosu), które należy różnie interpretować w zależności od np. prefiksów. Zajrzyj sobie do źródeł pierwszego lepszego deasemblera np. HDE, LDE etc.

@Bartosz Wójcik No faktycznie idąc tym tokiem rozumowania to dosyć mocno uszczupliłbym liste instrukcji, nie pomyślałem ;D

Ostatecznie, spojrzałem do manuala. Okazuje się że opkody podzielone są na grupy według trzech bitów ModRM i bajtu opkodu.
Tak to wygląda.
Mogłem spojrzeć do manuala przez założeniem tematu ; d (RTFM troche).
Anyway jakby ktoś miał taki problem to może wpadnie na ten temat.
Solved.

No generalnie na razie nie zajrzałem w miejsce w które powinienem zajrzeć najpierw, manual od 8086, dosyć trudny w odbiorze ;p

Moim zdaniem łatwiejsza w odbiorze jest dokumentacja AMD niż Intela.
AMD64 Architecture Programmer’s Manual
Intel® 64 and IA-32 Architectures Software Developer’s Manuals

To są grube tomiszcza opisujące aktualne wersje procesorów (czyli z trybem 64-bitowym, zestawami instrukcji jak SSE4, AVX) z czego 90% nie będziesz potrzebował do emulacji poczciwego 8086, który miał tylko 16-bitowe rejestry i tryb rzeczywisty, ale jeśli chcesz poznać działanie procesorów i kodowanie instrukcji, to są to dokumenty "bardzo fajne".

No i oczywiście prawie nikt już dzisiaj nie ma starego 8086, więc większy sens jest pisać emulator w oparciu o dzisiejszy standard, nawet jeśli ograniczony do trybu rzeczywistego.

Nie będę się rzucał na emulacje nowoczesnych procków bo o SSE/* i tych innych bajerach to już w ogóle nie mam zielonego pojęcia, może kiedyś.
Na razie napisze sobie jakiś prosty emulatorek 8086 co też w sumie (chyba?) takie aż banalne nie jest. Natomiast niezmiernie ciekawe, tylko te kodowanie intela nie jest najprzyjemniejsze, ale to pewnie tylko kwestia że trzeba sie z nimi porządnie zapoznać. No, ale na razie to napisze porządnie disasm żeby nie rzucał wyjątków na żadnej (nawet dziwnej ale poprawnej) instrukcji ;p
BTW @Azarien pisałeś emulator? (bo tak z komenta wynika) Jak tak to czego?