Názory k článku Další instrukce zpracovávané v Benderově hlavě
-
Pavel TišnovskýZlatý podporovatelAle teoreticky se to dá ověřit, protože jeho hlava teď leží někde poblíž Area 51 :-) -
Tomas Z. (neregistrovaný)Teoreticky (pokud ji opravdu nezná, některé instrukce třeba jen nejsou dokumentované) může udělat cokoliv :)
V praxi moderní procesor typicky vyvolá přerušení, které (zjednodušeně řečeno) může v posix systémech vidět jako SIGILL
. -
Pavel TišnovskýZlatý podporovatelJe to opravdu různé. Starší mikroprocesory (většinou osmibitové) prostě takovou instrukci ve svém řadiči "nějak" dekódovaly a potom spustily. Většinou z toho vylezla úplná blbost, že se třeba na ALU poslal příkaz pro současné provedení dvou operací atd. Někdy se to dalo využít (třeba na 6502, když už jsme u toho Bendera :). Novější mikroprocesory buď mají všechny opkódy zaplněné nebo vyhodí výjimku.
Ještě existují nedokumentované instrukce, tj. instrukce, které výrobce z nějakých důvodů nezveřejnil. Třeba proto, že mnoho vyrobených mikroprocesorů mělo v daném místě chybu (výrobní postupy měly zpočátku třeba jen 30% úspěšnost), tak bylo lepší prostě instrukce, které v 70% případů nefungují, prostě nezveřejnit a vesele prodávat. Viz Z80 apod.
Motoroly zase byly známé svojí velmi vypečenou nedokumentovanou instrukcí HCF - Halt and Catch Fire :-) viz http://en.wikipedia.org/wiki/Halt_and_Catch_Fire
No a potom jsou instrukce, které lze nedokumentovaným způsobem rozšířit: viz dělení libovolných 8bitovým číslem i na 80186 pomocí instrukce pro dekadický převod, přechod z protected módu do reálného režimu na 80286 atd. -
Pavel TišnovskýZlatý podporovatelBudu teď mluvit za 6502ku, tam to mám vyzkoušené. Podívej se třeba na http://www.llx.com/~nparker/a2/opcodes.html. Třeba opkód AF vyvolá ve skutečnosti dvě instrukce LD, jednom pro registr A a podruhé pro X, což ještě projde, ale "dvojitá" ST už samozřejmě ne. Těch kombinací je tam víc, protože 6502 (ta originální) nechala v 256 možných kombinací spoustu volného místa.
-
Pavel TišnovskýZlatý podporovateljj, však říkám, že toto ještě bude fungovat (a je to docela dobrá instrukce), ale "paralelní" ST (třeba STA a STX) popsané v dalším odstavci už ne, ledaže by to ještě předtím udělalo nějakou logickou operaci nebo něco podobného :-)
-
Kvakor (neregistrovaný)Nektere nedokumentovane instrukce u Intelu byly celkem hojne vyuzivany - naprikal LOADALL, ktery byl nejspis navrzen k ladeni samotneho procesoru. Na i80286 se s nim daly delat zajimave veci, jako napr. sahat nad 1MB hranici i v realnem rezimu. Pokud vim, tak minimalne HIMEM.SYS LOADALL pouzival. Vice viz http://en.wikipedia.org/wiki/LOADALL .
Na i80386 a novejsich ale nebyl treba, protoze ty se daly prepinad do a z chraneneho rezimu bez problemu, kdezto u i80286 ho slo jen zapnou, vypinal se resetem pres radic klavesnice, po nemz se vracel na adresu nastavenou v CMOS pameti ... proste husta magie.
Ale i80386 zase mely treba nedokumentovany rezim, tzv. unreal rezim, kde slo pomoci manipulace s limity segmentovych registru (nastavenych v chranenem rezimu) sahat v realnem rezimu v plnem rozsahu 4GB pameti (tj. 16bit segmenty, ale 32bit ofsety). Sice byl problem tam vykonavat kod (kvuli presuseni), ale ten se vetsinou pod hranici 1MB vesel.
Bohuzel to ale nefungovalo ve v86 rezimu, tedy s pametovymi manazery a Windows, tak se to moc neujalo. Ale vsechny procesory ho od te doby podporuji (vcetne emulatoru), protoze to pouzivaji BIOSy na veci jako testy pameti a podobne. Vice viz http://en.wikipedia.org/wiki/Unreal_mode . -
martin (neregistrovaný)Tak trochu to záleží na mikrokódu procesoru(řadiče), jak se zachová. Nevím jak v reálu, ale na výukových procesorech DOP je každý operační znak postupně dekódován na základě bitů v Instr. Registru a v případě neznámé kombinace se je proveden NOP, resp. se přechází do stavu kontroly, zda nedošlo k nějakému přerušení.
Obecně, co procesor, to jiné řešení. -
peteb (neregistrovaný)Tento clanek mi pripomel zlate casy okolo roku 1986 a muj prvni pocitac Comodore C=16.
Ten mel v takzvanem Monitoru primo v ROM vyborny assembler a disassembler prave pro tento typ CPU. A nektere veci se proste nezpamoninaji #FF15 registr barvy pozadi. ;-)
Holt to byla jina doba, kdy se kolem pocitacu se motali pouze lide, kteri je bud meli radi a nebo jim rozumneli. -
Geralt (neregistrovaný)Dobry den,
chtel bych se zeptat, proc se pri aritmetickem bitovem posunu zachovava hodnota nejdulezitejsiho bitu. Napriklad pokud bychom meli ctyrbitove cislo, rekneme 1011 (tj. 11 desitkove), tak pri pouhem posunuti bitu doprava dostavame 0101 (tj. 5 desitkove), coz je spravny vysledek pro 11/2 celociselne. Naopak pokud nejvyssi bit zachovame, dostaneme 1101 (tj. 13 desitkove).
Tuto zalezitost nejak nemuzu pochopit, jinak vyborny clanek (i kdyz jsem oproti aktualnim dilum s cetbou trochu pozadu), diky Geralt -
Pavel TišnovskýZlatý podporovatelDobry den,
ano, pri aritmetickem posunu se hodnota nejvyssiho bitu zachovava a to z duvodu pouziti reprezentace cisel ve dvojkovem doplnku. Protoze (pokud bereme cisla ulozena na ctyrech bitech ve dvojkovem doplnku) 1011 neni 11 desitkove ale -5 desitkove a po aritmetickem posunu dostaneme vysledek 1101 coz je -3 desitkove a to lze povazovat za korektni vysledek deleni 2 (protoze nejnizsi bit se ztrati, tak neni rozdil mezi delencem -5 a -6).
Jazyky, ktere znaji rozdil mezi (signed int) a (unsigned int), treba C-cko, tak sice maji pouze jeden operator >>, ale ten se ve sve cinnosti bud preklada jako aritmeticky posun nebo bitovy/logicky posun. Jine jazyky, ktere tento rozdil neznaji (Java), musi zavadet novy operator >>>. V assembleru to same - pri pouzivani "zapornych cisel" se pouziva aritmeticky posun jinak bitovy.
Pavel T.
