Instrukce
Jestliže mnemonika označuje co daná strojová instrukce dělá, její operandy určují s čím. Jinými slovy, operand určuje zdrojová nebo cílová data, nad kterými daná strojová instrukce pracuje. Operand bývá buď konstantou, nebo adresou v některém z paměťových prostorů počítače. Typicky jsou to adresový prostor registrů a operační paměti.
Instrukce
Strojové instrukce se dělí podle svého určení na přesunové, aritmeticko-logické a řídící instrukce. Výrobci většinou používají mnohem jemnější rozdělení (např. přesuny, aritmetické, logické, rotace, násobení a dělení, skoky, zásobníkové, systémové instrukce).
U některých architektur není situace tak jasná. Například přesunová strojová instrukce, která změní hodnotu v systémovém registru procesoru de-facto přebírá funkci systémové instrukce.
Podle možností daného procesoru se liší šířka operandů (8/16/32 bitů) a jejich typ. Některé procesory (např. PIC) mají pouze instrukce pro jednoduché operace s malými celými čísly (viz byte), jiné mohou přímo pracovat s čísly v plovoucí řádové čárce (např. dle standardu IEEE 754).
Záměrným vedlejším efektem provedení instrukce obvykle bývá určité nastavení příznakových bitů v procesoru, který za tímto účelem obsahuje takzvaný registr příznaků. Registr příznaků využívají především podmíněné skoky a instrukce pro přičítání nebo odečítání s přenosem. Způsob nastavování příznaků bývá obvykle pro určitou skupinu instrukcí stejný. Zvláštní funkci z tohoto hlediska zastávají instrukce pro porovnávání, protože nemění hodnotu svých operandů, ale pouze nastavují příznakové bity (anglicky flags).
Tyto instrukce mění buď tok programu, nebo způsob, jakým procesor funguje. Základní řídící instrukcí je instrukce skoku (typicky má mnemoniku JMP), která říká, že vykonávání programu nepokračuje následující instrukcí, ale instrukcí která je uložena na adrese definované operandem instrukce JMP.
Aby mohly být instrukce vykonávány procesorem, je nutno je uložit do polovodičové paměti, jako sekvence několikaciferných dvojkových čísel. Tato sekvence se nazývá strojový kód. Výrobce procesoru proto pro každou instrukci definuje, jakým způsobem má být zakódována do paměti počítače.
Tématem budou instrukce (služební, vrchnostenské, hospodářské, pro jednotlivé úředníky, pro členy konkrétní socioprofesní skupiny i jakékoliv další): předpisy či nařízení vymezující kompetence a stanovující, případně sjednocující způsoby jejich naplňování jak v soukromém, tak státním sektoru, určující vzájemné vztahy osob působících v dosahu dané instrukce, ale i konkrétní práva a povinnosti, včetně způsobů jejich naplňování a uplatňování v praxi.
Modul AVIX Shop Floor Viewer je perfektním řešením pro digitální pracovní instrukce. Správa pracovních úkonů a naměřených časů se provádí stejným způsobem jako v AVIXu, jen s tou výhodou, že je lze publikovat operátorům prostřednictvím webového prohlížeče. tím zajistíte, že operátoři mají vždy snadný přístup k nejnovější (aktualizované) verzi pracovní instrukce!
K tomu Archimedovi: údaj, že měl přes 4 MIPS je zavádějící. Acorn tohle tehdy náležitě rozmazával v reklamách, ale samozřejmě přitom nezmínil jistý "detail" a sice že ten procesor měl JENOM instrukce, které bylo možné vykonávat v jednom cyklu. Na rozdíl od M68000 u Amigy a ST neměl žádné složitější operace, například dělení a dokonce i násobení se muselo dělat čistě softwarově a výsledné rutiny samozřejmě vyžadovaly pár desítek cyklů. Archimedes byl ve své době úžasný počítač, znatelně rychlejší, než Atari a Amiga, ale ne osmkrát rychlejší, jak tvrdila propaganda.
Hm, proč bylo nulování horních 32 bitů kontroverzní? IMHO je to docela praktické - speciálně o virtuálních jazyků (JVM) používá běžně 32-bitová aritmetika (nebudu teď polemizovat o výhodách a nevýhodách) a následně se pak výsledek musí použít nějakým způsobem pro adresování. A v té chvíli se nemusí těch 32 bitů explicitně mazat. Opačný případ - že bych chtěl horních 32 bitů použít, když počítám spodních - si těžko dokážů představit. Snad jen load immediate, ale pro ty jsou stejně speciální instrukce a použití aritmetiky tam nedává moc smysl...
Ta kontroverze nějak souvisela s pointerovou aritmetikou - vývojáři překladačů chtěli moct používat 32 bitové instrukce pro výpočet adres prvků ve vektorech apod. Jinak s tím taky souvisí jedna zajímavá historka. Opkód 0x80, který se na x86 odjakživa používal jako NOP, byla ve skutečnosti opravdická instrukce. Pokud si vzpomínám, bylo to cosi jako MOV al, al bez aktualizace stavového registru. V praxi taková operace nemá žádný efekt a tudíž běžně suplovala jako NOP (který starý x86 jinak neměl). Ovšem u AMD nastal problém, že vzhledem k ostatním volbám návrhu (32 bitové instrukce se mají chovat stejně + nulování horních bitů) tenhle nevinný opkód najednou znamenal vynulovat čtyři horní oktety v rax! Takže už žádný NOP ale normální pořádná instrukce. U AMD proto předefinovali instrukční sadu tak, aby 0x80 znamenalo skutečný pravý NOP a stará nesmyslná operace s al se tak ztratila. Zkrátka, v zájmu zachování zpětné kompatibility AMD muselo změnit operaci, která nedělá nic, tak, aby nadále pořád nedělala nic, ovšem jiným a zpětně nekompatibilním způsobem :))
Rozhodně nechci ARM nijak shazovat, opravdu měl řadu na svou dobu zajímavých inovací a navíc Archimedes byl tuším jeden z vůbec prvních mikropočítačů s 32bitovou sběrnicí. I tak si ale myslím, že jablka se musí porovnávat s jablky. Uvažovat v MIPS má smysl všude tam, kde jde o tok instrukcí jako takových: při návrhu prediktorů, cache, sběrnice atd... Z programátorského hlediska je ale IMHO důležité jedině to, jak rychle dokáže procesor provést daný výpočet. Příklad budiž skalární součin čili násobení s akumulátorem (když už tu byla řeč o 3D hrách). Torzo takové smyčky bude - zjednodušeně - MOV-MOV-MUL-SHR-ADD. Dejme tomu, že pracujeme ve fixní čárce a s 16bitovými hodnotami, což bylo typické. Na M68 trvalo načtení 16 bitové hodnoty, s post-inkrementací ukazatele, 4 cykly. 16 bitové ADD byly (pokud se nepletu) taky 4 cykly. MUL bylo monstrum, trvalo tuším nějakých cca 50 cyklů (!). Shift o 16 bitů se dělal instrukcí SWAP, která sice trvala 26 cyklů ale kupodivu to bylo pořád rychlejší, než obecné instrukce shift. Celkem to dává 88 cyklů při taktu 8 MHz (na Atari ST. Amiga běžela na 7 MHz). Na ARM trval load z RAM (předpokládám) 1 cyklus, shift a součet taky po jednom, MUL nebylo vůbec a muselo se dělat ručně. Buďme benevolentní a předpokládejme, že máme nějakou supr dupr rutinu, která to zvládne za 30 cyklů (u 16 bitových operand). Takže celkem 34 cyklů při 4 MHz. Suma sumárum, pokud mám ty čísla správně, tak to Archimedes teda zvládl o nějakých 13% rychleji, než nejrychlejší stroj s M68K. To není málo, ale je to přece jenom úplně jiná realita, než co se tehdy snažil vsugerovat marketing o 4 MIPS versus 0.5 MIPS.
Dnes už si to nepamatuji zcela přesně, měl jsem A4000 a dost pro něj programoval v asm (nebo kombinaci BASIC+asm), ale s tím jedním cyklem to není pravda (alespoň pro ARM250). Většina instrukcí 1 cyklus, pár 2 taktových (v nějakých kombinacích) a nejdelší paměťové (LD, ST) 4 cyklové. Ale knížku jsem prodal s počítačem, takže nemám, kam se podívat. Naopak shifty se dělaly v barell shifteru jako součást jakékoliv instrukce, takže i násobení se dalo napsat velmi rychle - trošku "roztahat" smyčku, použít posun a podmínku jako součást instrukce sčítání...
Co se týče nulování horních 32-bitů 64-bit registrů, tak v každém případě zachování původního obsahu (tak jak je to při 16-operacích na 32 x86) je ta nejhorší možní volba. Znamená buď zduplikovat logiku přejmenovávání registrů na každou půlku zvlášť a řešit instrukce tak, jako by měly dvojnásobný počet vstupních závislostí anebo ponechat regsitru v rámci přejmenovávání v celku a řešit každou 32-bitovou operaci, která zapisuje výsledek do jiného registru než jsou vstupy, jako operaci s další vstupní závislostí na předchozím obsahu výstupního registru. Efekt přerušení závislostí/přejmenování v daném výstupním registru se tedy nekoná. 041b061a72