Názory k článku
Další instrukce zpracovávané v Benderově hlavě

Tý jo, ten titulek mne zmátl. Bender, Bender, kde já to jen slyšel... Futurama... To nějak souvisí s grafikou? Nebo je to nějaký rootovský výstřelek? Klik.

Jinak díky za (již tradičně) skvělý článek.

leda ze bys slysel Blender. Vypada to podobne.

Bender Bending Rodriguez je pohanen MOS 6502 mikroprocesorem (jak ukazuje rentgenovy snimek jeho hlavy z jednoho dilu Futuramy....navic to ukazuje nadcasovost tohoto 8-mi bitoveho kousku, protoze se vyuziva v roce 3000 A.D. k rizeni robotu:) ).... takze proto :)

On ma castecne mexicky puvod?

Ne jen castecne, ale uplne. Byl, nebo spise bude smontovan v meste Tijuana v Mexiku :)

Ale teoreticky se to dá ověřit, protože jeho hlava teď leží někde poblíž Area 51 :-)

Nac se spokojit s hlavou, kdyz nekde v New Yorku cekaji stovky kopii Bendera s cennostmi z minulosti, aby je mohli predat tem emzakum (Bender's Big Score) :) Ne jen, ze pisete skvele clanky, jeste ke vsemu znate Futuramu :)

jojo, Bender je prostě supr;) Ale Fry taky:) jinak na wewewe.futurama.sk jsou 2 serie ve flashplayeru - doporucuju nez si sezenete serial na thepiratebay.org(celej ma 13Gb-jeden dil 175Mb). Ale problem je sehnat titulky:(

Docela by mě zajímalo, co se stane, když pošlete instrukci, kterou procesor nezná.

Zamrzne? Resetne se?

Pokud instrukci nezná, tak by neměl pokračovat dál, protože nezná ani počet parametrů nebo jak je instrukce dlouhá.

Jak je taková "chyba" ošetřena?

Díky

Nevim přesně. Ale domnívám se že záleží na konkrétním tipu procesoru/architektury.

Záleží na architektuře. Většina nových procesorů vyvolá výjimku nebo přerušení. Některé starší procesory berou neznámý operační kód jako NOP. U některých architektur prostě neznámá instrukce neexistuje.

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

.

Je 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.

Dvou operaci naraz? To jako dva budice sbernice smazily do sebe? Neslehaly z procesoru plameny kdyz se takova instrukce poustela porad dokola?

Podle me to je IMHO blbost. V Z80 jsou na neznamych instrukcich zrcadla a instrukce co delaji nejake nedokumentovane (uzitecne veci).

Budu 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.

AF executes AD ("LDA absolute") and AE ("LDX absolute") at the same time, putting the same value in both the accumulator and the X register.

jj, 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 :-)

ja viem, len som chcel aby to bolo pochopitelne na prvy krat priamo z tejto diskusie...

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 .

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í.

Procesor neudělá nic, protože řadič instrukcí neví co má udělat, proto se dělat nebude nic, bude to jako NOP.
Ale zas záleží na architektuře procesoru. Jsou jen 2 možnosti co to udělá: jako NOP, nebo to zamrzne.

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.

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

Dobry 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.