Tester x86 (zejm.) ALU instrukcí

[mhi]

Doporucite mi prosim nekdo nejaky blob na testovani x86 emulatoru (translatoru), aby to umelo v idealni podobe:

- otestovat oddelene 16 a 32bit ruzne ALU operace (tzn. aby slo testovat jen 80(1,2)86 sadu) - na spravny vypocet
- to same na SPRAVNOU praci s flagy
- otestovat ruzne silenosti typu https://www.timdbg.com/posts/useless-x86-trivia/
- otestovat ruzne dalsi instrukce pro pametove operace, opet oddelene 16 (80(1)86) a 32bit (386+) rezim

Jde mi primarne skutecne jen o ALU. Znam treba https://github.com/barotto/test386.asm - takhle presne si to nejak predstavuju, tam bohuzel to ALU +/- chybi.

Doplnujici otazka - potrebuju neco podobneho i na jine sady, konkretne PowerPC a TriCore, 8051,  80166, Z80. Opet primarne zamerene na ALU, nepotrebuju zadne veci jako testy MMU apod.

Po minulych zkusenostech se nezlobte, ale na reakce rikajici mi ze delam blbost nebo ze to mam udelat jinak (pokud to nebude z meho pohledu dobry napad) nebudu vubec reagovat.

[Reklama]

[alex6bbc]

a co to vykuchat to z existujicich opensource emulatoru? qemu.

[RDa]

A nejde vygenerovat brute force metodou vsechny kombinace instrukci a druhu parametru, vcetne ocekavanych side efektu (flagy, vystupy), ktere lze pak overovat na testovanem blackboxu? U IMM muzes vygenerovat nekolik ruznych kombnaci konstant.. nemusi se pokryvat cely 16/32b prostor.

Klidne se z toho da udelat pak jeden exac, pospojovanim dilcich testu, oddelenych s assertions.

[mhi]

Dekuji za odpovedi,

ad qemu: tam toho zase tak moc nevidim, nejzajimavejsi je asi toto https://github.com/qemu/qemu/blob/master/tests/tcg/i386/test-i386.c - jenze to neresi uplne muj problem, potrebuju intenzivnejsi testy. Prusvih jsou takove ty ruzne drobnosti typu ze nejaka instrukce nastavuje nebo nenastavuje flagy, obcas se treba parity flag pouziva na neco obskurniho, apod. (ne ze bych tohle zrovna potreboval, to se v mem prekladanem kodu nebude vyskytovat, je to jen priklad).

ad bruteforce: pokud udelam skutecne bruteforce, tak to bude neskutecne dlouhe. Dlouhe to bude i kdyz omezim sady tech imm konstant a vstupu. Po precteni mne napadlo jeste udelat random testsuite, ze by to generovalo pseudonahodne ruzne testovaci sady (zkusime co udela adc nad signed pos a neg 8bit cislem, a pak zkusime jestli jnX bude fungovat vzdy stejne (a preskocime podminene dalsi testovaci pseudorandom kod).

Jinak tohle je reset kod pocitace TNS HC16:

Kód: [Vybrat]

seg000:E104 reset_routine   proc near
seg000:E104                 sub     ax, [bx+si]
seg000:E106
seg000:E106 loc_FE106:                              ; CODE XREF: int9_irq1_kbd+100
seg000:E106                 cli
seg000:E107                 cld
seg000:E108                 xor     ax, ax
seg000:E10A                 sahf
seg000:E10B                 jb      short err01
seg000:E10D                 jz      short err01
seg000:E10F                 jp      short err01
seg000:E111                 js      short err01
seg000:E113                 daa
seg000:E114                 or      al, al
seg000:E116                 jnz     short err01
seg000:E118                 not     ah
seg000:E11A                 sahf
seg000:E11B                 jnb     short err01
seg000:E11D                 jnz     short err01
seg000:E11F                 jnp     short err01
seg000:E121                 jns     short err01
seg000:E123                 daa
seg000:E124                 cmp     al, 66h ; 'f'
seg000:E126                 jnz     short err01
seg000:E128                 mov     ax, 5555h
seg000:E12B                 cmp     al, ah
seg000:E12D                 jnz     short err01
seg000:E12F                 shl     al, 1
seg000:E131                 or      al, ah
seg000:E133                 cmp     al, 0FFh
seg000:E135                 jnz     short err01
seg000:E137                 mov     ah, al
seg000:E139
seg000:E139 loc_FE139:                              ; CODE XREF: reset_routine+4Fj
seg000:E139                 mov     ds, ax
seg000:E13B                 mov     bx, ds
seg000:E13D                 mov     es, bx
seg000:E13F                 mov     cx, es
seg000:E141                 mov     ss, cx
seg000:E143                 mov     dx, ss
seg000:E145                 mov     sp, dx
seg000:E147                 mov     bp, sp
seg000:E149                 mov     si, bp
seg000:E14B                 mov     di, si
seg000:E14D                 sub     ax, di
seg000:E14F                 jnz     short err01
seg000:E151                 shl     cx, 1
seg000:E153                 jnb     short loc_FE139
seg000:E155                 jmp     short loc_FE159
seg000:E155 ; ---------------------------------------------------------------------------
seg000:E157                 db  90h ; É
seg000:E158 ; ---------------------------------------------------------------------------
seg000:E158
seg000:E158 err01:                                  ; CODE XREF: reset_routine+7j
seg000:E158                                         ; reset_routine+9j ...
seg000:E158                 hlt



[RDa]

On ten bruteforce neni zas tak velky, mnozina kombinaci operandu / adresnich rezimu a typu instrukce bude konecna. Nejvetsi objem do toho vnasi hodnoty nad kteryma operujes a tam staci vygenerovat nejaky random bordel (treba hash funkci) plus par zajimavych hodnot (-1,0,1) a pak to tim prohnat. Automaticky wrapper by pak operand pred-vlozil do spravneho registru nebo na spravnou adresu a otestoval vystup.

Pripadne si proti svemu VM pust tohle - https://github.com/xoreaxeaxeax/sandsifter - a zjisti ti to veskere podivne chovani :)

[Reklama]

[anonacct]

Teoreticky ty instrukce nemusíš ani emulovat.

Existoval takový projekt, WinREPL, který ale autor archivoval a už je jen tady (https://github.com/zerosum0x0-archive/archive) - a ten ty instrukce JIT zokpiloval a pustil, takže člověk dostal přesný výsledek.

Na druhou stranu 16-bit assembler - to je něco tak historického, že tím se dnes moc lidí teda nezabývá.

[Kizarm]

Je vidět, že jdete dost do hloubky. Snad by vám mohl pomoci třeba dr. Pavel Píša (https://cmp.felk.cvut.cz/~pisa/) & kol. Dělají mj. simulaci procesorů, co vím tak MIPS a RISC-V, ale obecně učí architektury počítačů, takže i X86. Nějaká testovací sada existovat musí, je ale otázkou zda to nemají výrobci specificky pro daný čip a ještě k tomu pod NDA.
Ono je to vůbec problematické. Pamatuji dobu, kdy se CPU skládaly z TTL obvodů, tam měly testy jakýsi smysl, ale obvykle chyba v CPU způsobila nefunkčnost už v bootloaderu, takže nešlo test dostat do RAM a tudíž ani spustit. V simulaci to bude podobné. Pokud na tom spustíte jakýkoli komplexnější program a funguje to podle předpokladu, dobře. Pokud to funguje divně nebo vůbec, pak se chyba dost blbě hledá.

[RDa]

Ono je to vůbec problematické. Pamatuji dobu, kdy se CPU skládaly z TTL obvodů, tam měly testy jakýsi smysl, ale obvykle chyba v CPU způsobila nefunkčnost už v bootloaderu, takže nešlo test dostat do RAM a tudíž ani spustit. V simulaci to bude podobné. Pokud na tom spustíte jakýkoli komplexnější program a funguje to podle předpokladu, dobře. Pokud to funguje divně nebo vůbec, pak se chyba dost blbě hledá.

Tohle je prave falesny pocit jistoty. Pokud chcete mit solidni implementaci, tak ji musite byt schopen otestovat - a chybu odhalit jinak - na nizke urovni, nez tim, ze vam sehlava javascript v prohlizeci. V podstate je to stejny pristup jako u testbenche pro HDL kod - kdy jeste mate sanci vychytat nejake implementacni bugy, nez za hodne milionu nechate vyrobit masku, pripadne spustite vyrobu produktu.

Ostatne testovaci vektory se pouzivaji i na hotovych cipech, kvuli urceni, zda jsou vubec funkcni.

Jako chapu autorovu potrebu mit testovaci sadu, a z duvodu dvojite chyby by takovy test mel napsat nekdo jinej nez on. A az budou mit oba hotovo, tak to muzou poustet behem vyvoj dokola a dokola.. a odhalovat pripadne regrese v kodu.

Imho INTEL takove testovaci/verifikacni sady ma.. ale nebudou verejne dostupne.

Kluci z Centaur Technology resili podobny problem:
https://www.cl.cam.ac.uk/~jrh13/spisa19/paper_08.pdf

[anonacct]

Ale hlavně X86 instrukční sada má hodně dokumentace, a pokud někoho zajímá jen ALU, tak to není až tak moc instrukcí. Takže prostě jednu za druhou implementovat, udělat tester té implementace a porovnat to s nativním kódem.

Jinak možná bych se podíval i na valgrind, ten taky umí emulovat kde co

[CPU]

Kdyby z toho čouhal balík peněz, tak bych se tomu docela rád věnoval.

[alex6bbc]

Kdyby z toho čouhal balík peněz, tak bych se tomu docela rád věnoval.

z toho couha leda hafo roboty :-)

[CPU]

Nojo, ale není lepší, když z tohou čouhají i prašule :-D ?
Já rád prašule... 

[alex6bbc]

Nojo, ale není lepší, když z tohou čouhají i prašule :-D ?
Já rád prašule... 

to vsichni radi :-)

[CPU]

No já nejsem náročnej, stačil by mi plat programátora v nějaké neziskovce, třeba v Thunderbirdu má programátor 20 000 dolarů. S tím bych neměl problém. Pak bych klidně dělal i nějaký free melouch :-D

[mhi]

Jako chapu autorovu potrebu mit testovaci sadu, a z duvodu dvojite chyby by takovy test mel napsat nekdo jinej nez on. A az budou mit oba hotovo, tak to muzou poustet behem vyvoj dokola a dokola.. a odhalovat pripadne regrese v kodu.

Nakonec to asi budu muset naprogramovat sam. Zvazuju jestli mam vubec resit PF. A jestli ma smysl AF. V target kodu se myslim ani jedno nepouziva, ale muzu se samozrejme plest. PF vyresit muzu celkem snadno tim, ze si nekam po ukonceni translace basic bloku NEBO informaci ze potrebuju plne flagy ulozim vysledek a pak pouziju lookup table, to same na ten AF, jen to jsou uplne zbytecne cykly navic.

K otestovani jsou:

- vypocty EA
- prehozy mezi registry: pushpop, segmentove
- ALU operace rozdelen i na 8  / 16 / 32 bitu a ruzne formaty zapisu X testy ruznych flagu x ruzne vstupy (rozdily horniho bitu, preteceni, apod.).

Prvni reseni bude asi udelat nejakou tabulku, ktera bude obsahovat tyhle ruzne vektory a pak nejspis pres random nagenerovat sadu testu, kde si treba na stacku budu naxorovavat vysledky, a srovnam realne CPU vs. translaci. Sice to neni idelani, ale odhali to asi spoustu chyb. Nektere vyzivnejsi sady si ulozim jako testvektory.

Jsem zvedav, jestli najdu i nejakou chybu v nejakych emulatorech a jestli to treba dobehne dobre na Win/ARM .