Názory k článku Mikroprocesory s architekturou ARM

Podle wikipedie je to taky 4,77MHz a 9MHz...jestli se tomu dá věřit :-)

Koukal jsem na CZ, v EN píší 5-10MHz :-D Aby to nebylo jednoduché...

V počítačích Schneider EURO PC II byl procesor 8088/9,54 MHz.

díky

... rozdíl oproti typickým mikroprocesorům s architekturou CISC, u nichž je délka instrukcí proměnná a mnohdy může přesahovat hranici slov (což ve svém důsledku vedlo k nutnosti vytvoření takzvané „fronty instrukcí“, jejíž vlastnosti se mj. využívaly či spíše zneužívaly při tvorbě virů, které nešlo odhalit debuggerem).

Byl by nějaký odkaz na relevantní informace? Ta fronta je snad implementována na úrovni HW a nedá se softwarově ovládat... nebo jsem mimo?

Jenom pro upřesnění - instrukční fronta byla už u 8086 (6 bytů) i 8088 (4 byty). Různý programy to využívaly na rozlišení, jestli běžej na 8088 nebo 8086.

Jinak vznik fronty instrukcí u 8086 nebo 8088 je asi dán snahou urychlit zpracování programu. Nejkratší instrukce (nějakej MOV) trvá 2 takty, ale čtecí cyklus z paměti 4 takty. Takže se procesor pokoušel přednačíst pár bajtů dopředu, pokud prováděcí jednotka dělala nějakou delší instrukci.

Nejsem si uz jisty, ale neni nejkratsi nejake DAA, INC nebo neco podobneho, co pracuje s jednim registrem, idealne s AL nebo AX? I kdyz popravde receno jsem pro x86 psal assembler tak pred deseti lety a byl to dost humus, v porovnani napriklad s cistym assemblerem 68000, ktery se spis podobal cecku :-)

Nasobicka ARM-1 nepracovala 'paralelne' se zbytkem chipu (ARM-1 neni superskalarni). Vlastne vyuzivala jiz pritomnou ALU, tedy jeji scitacku a barrel shifter a nejaky sekvencni obvod tyto ridil tak aby realizovaly Boothuv algoritmus nasobeni (neco jako pisemne nasobeni, ale po 2 bitech naraz (vyuziva se toho ze x*3 je vlastne (x<<2)-x)) takze nasobeni trvalo az 16 taktu kdyz byly bity ve druhem ciniteli zaplnene az do pozice 31. Dokonce i novejsi jadro ARM7TDMI nasobi sekvencne ale uz ma v sobe asi nejake tabulky na nasobeni 32bitu*8bitu, takze nasobeni trva 2 az 5 taktu (podle obsazenosti druheho cinitele), MAC (multiply-and-accumulate) jeste o takt vic.

Problem je ze tato cinnost neni pipelinovana (jako na novejsich CPU), takze program nemuze do nasobicky kazdy takt nacpat nova data s tim ze je bude potrebovat az za 5 taktu -- tady se musi vzdy cekat -- scitacka je jen jedna a pouziva se u temer vsech instrukci, dokonce i pri adresovani -- load a store instrukce umoznuji pricist k bazove adrese registr a ten (volitelne) inkrementovat -- to vse se provede jedinou instrukci behem nacitani dat z pameti. I relativni skok pouziva scitacku z ALU.

Trochu je to videt z nakresu jednotek a sbernic pres ktere si muzou posilat data:
http://en.wikipedia.org/wiki/File:Diagrama_ARM7.jpg

Jejich filosofii pri navrhu bylo aby pokud mozno kazda cast chipu byla v kazdy okamzik k necemu vyuzita. To nevede k nejrychlejsimu chipu -- treba dedikovana pipelinovana nasobicka jde proti teto filosofii -- ale vede to k malemu poctu transistoru a male spotrebe.

Taky je to dusledek toho ze ARM je dilem 2 lidi (podobne jako puvodni UNIX) a ne armady inzenyru, kde jedno oddeleni dela dekoder instrukci, dalsi scitacku, dalsi adresovou jednotku, dalsi jeste neco jineho a nad tim bdi system integrator, ktery jim definuje protokoly pomoci kterych si ty jednotku budou povidat. A i kdyz se pak zjisti ze implementovali tutez vec 2*, vetsinou uz se s tim neda nic delat.

Jinak ARM ma opravdu velmi malou spotrebu, nekde na netu se da najit video kde Steve Furber vypravi jak na jednom z prvnich chipu chtel merit spotrebu, mel ho pripojeny na sbernici 8-bitoveho BBC-micro, na kterem delali vyvoj a nechal si na obrazovku v nekonecnem cyklu neco vypisovat. Pak chtel ARM odpojit od napajeni aby tam vlozil ampermetr a zjistil ze i bez napajeciho napeti pocita dal. Nakonec se to vysvetlilo --- bylo to tim ze na sbernici byly nejake bity v log. 1 a pres ochranou diodu na pinech ARMu se to napeti dostalo na Vcc a odebirany proud byl tak maly, ze sbernice 'utahla' cely procesor.

Pekny bylo taky jak to vyvijeli --- Steve Furber mel na starosti obvodovou realizaci a Sophie (tenkrat jeste Rodger) Wilson vymyslel instrukcni soubor a napsal v tom svem BASICu simulator (myslim ze na urovni hradel ale uz si to moc nepamatuju). Takze na 8mibitovych pocitachich BBC micro vyvinuli 32bitove. Krome nich na tom pracovalo tusim 30 dalsich lidi z Acornu a nejaci inzenyri z VLSI technologies, kteri meli na starosti fyzickou vyrobu (2 vrstva CMOS, 3um sirka cary). Furber taky vypravel ze meli velke problemy tak maly chip pripojit k tehdejsim standardizovanym pouzdrum a tak dlouhe bondovaci dratky pak vypadaly divne.

Uplne jim takovy vyvoj zavidim, museli si to pekne uzit (od zacatku do vyroby prototypu to stihli za 18 mesicu).

V clanku jeste nesouhlasi pocet registru. Urcite jich neni 37. Najednou je pristupno 16 registru, preruseni a ruzne vyjimky pak maji vlastni link-register a stack-pointer. Myslim ze to bude neco kolem 26 registru, protoze i ARM7 ma dohromady 31 registru.

Tady je mozne se podivat na prototyp: http://acorn.chriswhy.co.uk/Computers/A500.html

Ano myslel jsem ARM-2, ARM-1 nasobicku nemel, nejak jsem se prepsal. Dik za opravu. Mozna dokonce ten Boothuv algoritmus meli az u ARM-3 a ARM-2 nasobil 'pisemne', uz si nejsem uplne jistej.

K tem registrum: 26bitove verze ARMu coz ARM2 byl, nemely jeste CPSR, stav byl soucasti registru 15, coz byl instruction pointer v jehoz nekterych bitech byly flagy a stav procesoru. IMHO to bylo roztomile reseni, protoze pri navratu z preruseni (i z podprogramu) se automaticky obnovil stav procesoru, jen to melo nevyhodu ze kod nemohl byt delsi nez 2^26 bytu a nedaly se pridavat nove flagy (coz se pozdeji stalo kdyz zavedli saturacni aritmetiku chteli mit flag ze doslo k saturaci).

Takze pak zavedli CPSR a SPSR registry aby mohli r15 prodlouzit, cimz to trochu zprasili, protoze pak musela instrukce rozlisovat jestli se tez obnovuje stav nebo ne, a prepnuti kontextu se zmenilo z jednoduche LDM/STM sekvence na nocni muru (ovsem v porovnani s tim co dokazal vymyslet v podobnych pripadech Intel je to stale prochazka ruzovym sadem, jen uz to postrada puvodni eleganci).

r8 a r9 ve FIQ modu maji az novejsi ARMy, napr. ARM7. ARM2 je nemel.

Takze (r0-r15) + (r13-r14)*3 + (r10-r14) = 16 + 3*2 + 5 = 27

Ja myslim ze ne. Kdyz bych v ARM rezimu skocil na adresu nedelitenou 4ma tak dojde k prefetch abort exception -- sice teoreticky bych se z ni mohl nejak vratit, ale na prakticke vyuziti by to bylo prilis pomale. Ja ve svem OS tyhle vyjimky akorat chytim a vypisu posmrtnou zpravu na ktere adrese k tomu doslo a resetuju CPU.

Přejmějšlím, jestli je možný, aby se jedna a ta samá sčítačka používala u výpočtu adres pro load/store, pro relativní skoky a i pro sčítání jako ALU operaci. Musím doma vyhrabat knížku, kde je kolik taktů která instrukce na ARM2 trvá, ale to by load/store a skoky nemohly trvat jeden takt, ne?
I blbá 8086 měla zvláštní sčítačku na sčítání segmentu a offsetu, 80186 měla další zvláštní sčítačku i na výpočet offsetu z báze nebo indexu.

To by asi řešila 16bitová sčítačka. Nebo čtení instrukce v pořadí první - třetí - druhej bajt :-)
Ne, pořád po těch letech nemůžu přijít little endianu na jméno. A to všechno kvůli sériovejm pamětem u Datapointu 2200. I Stan Mazor přiznal, že to byl omyl: http://silicongenesis.stanford.edu/transcripts/mazor.htm

Ja zase little-endian povazuju za prirozene poradi. Asi je to tim ze jsem zacinal na 6502 a pokracoval na Intelu. I ten ARM je little endian (protoze jeho tvurci sami priznavaji ze chteli neco jako 6502, tak rychleho aby programy v BASICu na tom bezely tak rychle jako rucne optimalizovany assembler na 6502). Pozdeji ho upravili na bi-endian, takze se to da nejak prepnout. Uprimne jsem to ale nikde nevidel v big-endian konfiguraci pouzivat.

Jinak 16-bitova scitacka v situaci kdy stejne musim nacitat data po 8mi bitech by bylo plytvani transistory.

A jakou výhodu vlastně "velkej indián" má?

load trva 3 takty, store trva 2 takty. Aritmeticke instrukce a MOV z registru do registru trva 1 takt. Tohle je az do ARM7, ARM9 uz ma cache takze si muze dovolit predstirat harwardskou architekturu, a tam LOAD i STORE zabere 1 takt, pokud to chyti cache (taky ARM9 ma 5-stage pipeline, ARM1-7 maji jen 3 stage takze pri stejne technologii nejdou taktovat tak vysokymi frekvencemi jako ARM9).

Duvod proc to trva 2 takty je ten ze ARM1 az ARM7 jsou von-Neumann stroje, takze maji jen jednu sbernici do pameti a jelikoz jsou pipelinovane tak by v kazdem taktu musely nacitat dalsi instrukci a nemely by kdy nacist/ulozit data. Proto se pipeline musi pozdrzet a udelat mimoradny pristup do pameti na jine misto. Nejaky detail navrhu komunikace s pameti (myslim ze se adresa posila o pul taktu driv nebo tak neco -- Furber to jednou nekde vysvetloval, ze to bylo takhle levnejsi udelat ale uz si nepamatuju v cem to vezelo) zpusobuje ze pri cteni to trva jeste o takt dyl nez by clovek rekl ze by muselo).

Pristup k pameti ale neni vzdy tak pomalej, procesor ma instrukce LDM a STM, ktere podle bitove masky na nejakou adresu (z nejake adresy) ulozi (nactou) registry jejihz bit v masce byl jednickovy. LDM trva 2+pocet registru, STM 1+pocet registru.

Vyborne se to hodi treba na zacatku a konci funkce kde se tak daji ulozit registry jedinou instrukci misto sekvence push r1 push r2 push r3 ...

Taky se to da pouzivat pri kopirovani bloku dat.

Mimochodem ta blba 8086 s jeji zvlastni scitackou pro scitani segmentu a offsetu mela stejne transistoru jako ARM2.

Aha, děkuji za objasnění.
To že měl ARM2 stejně tranzistorů jako blbá 8086 a polovinu jako ne až zas tak blbá 68000 jenom ukazuje, jak geniální návrh na tu dobu to byl.

Pokud by někdo měl zájem, tak za nějakou drobnost (kvalitní červené vínko, soudek Heinekenu :-) a odvoz (poštovné) daruji funkční Acorn Archimedes A4000 (ARM250, 4MB RAM, 80 MB HD, Acorn myš a klávesnici), plus podrobnou učebnci ARMu (včetně délek cyklů, jméno si teď nepamatuji a musel bych na půdu) a originál příručky RISC OS 3.

archimedes AT jirsoft DOT eu

Ono je to těžké, sice se s ním loučím nerad, ale už si ho nemám čas pustit. Assembler ARMu250 ale byl ten nejlepší, co jsem potkal (MOS6502 -> MC68000 -> ARM250, pak setkání s asm Intelu a tím jsem se na to vykašlal - to se prostě nedá...)

To muzeum je nějaké nefunkční, zž jsem tam před časem (dlouhým) psal a nic. Také existovalo nějaké "Křemíkové údolí" - muzeum, ale také asi už skočilo....

Takže asi tak.

V článku se motají dvě věci. První je situace v 80-tých letech, kdy byly tranzistory drahé a pomalé, 5 MHz procesor se tak dal provozovat s SRAM napřímo. Z této situace těžil RISC, protože pracuje s jednoduššími instrukcemi než CISC. Druhá je situace v dnešní době, kdy tranzistory jsou rychlé a velmi levné, ale rychlá paměť SRAM k nim je drahá a běžná DRAM je 10x-100x tak pomalá než by bylo potřeba. Z této situace těží CISC, protože má vyšší hustotu kódu.
Proto bude zajímavé sledovat co se stane v budoucnu, zda se objeví nějaká rychlá a levná RAM nebo což je pravděpodobnější výrobci CISC přejdou na 22 a 15 nm a konkurenční výhoda ARMu malá spotřeba bude ta tam.

Tahle úvaha předpokládá, že CISC (x86) má nějak dobře optimalizované kódování instrukcí. Ve skutečnosti rozdíl mezi RISC a CISC není až zas tak propastný, protože x86 (i x64) má kódování ušité horkou jehlou, kdy protahovali osmibit (8080) do délky. 8086 nebyl pro Intel prioritou, proto dopadnul, jak dopadnul. U x86 na jedné straně zabírají jednobajtové kódy nepoužívané (nebo minimálně používané) nesmysly typu DAA, XLAT, LAHF. CISCy komplexnější instrukce dnes už moc nepoužívají, protože se špatně optimalizují. Podívejte se na tabulku instrukcí u nejnovějších Intelů. Na některé se prostě vykašlali a trvají x taktů. A z x64 jich většinu vyházeli.
Na druhé straně RISCy mají občas instrukce (např. u ARMu podmíněný součet r1 a r2 s uložením do r3), které na x86 musíte nahradit několika (minimálně třemi v praxi spíš více) instrukcemi.
A mrkněte se někdy co vám leze z assembleru na x86, když překládáte céčkový kód. Protože má x86 málo registrů, tak je to samý PUSH, POP, čtení, zápis do lokálních tmp proměnných. Tohle všechno je u RISCů silně redukované.
Navíc má ARM i 16bitové kódování Thumb, které zkracuje délku kódu.
Navíc moderní x86 procesory do instrukční cache neodkládají x86 kód, ale tzv. microops, což je x86 přeložený do RISCových instrukcí.
Navíc např. Alpha (délka instrukce 32 bitů) nebo Itanium (41 bitů) vznikaly v době, když se o pomalosti pamětí dávno vědělo, takže tohle konstruktéři zjevně jako problém nevnímali.
No a taky moc nechápu, proč AMD, když už stvořilo nekompatibilní x64 aspoň trošku nezoptimalizovalo délku instrukcí a dokonce přidalo další prefixy, jednobajtové blbosti typu LAHF zachovalo...

Netvrdil bych to. Zaprvé CISC sada x86 je velice špatně optimalizovaná, takže pro využití výhod CISCu by bylo potřeba navrhnout sadu úplně novou (Intel to zkusil s Itaniem, což je EPIC, tedy ještě účinnější, než CISC, ale na trhu neuspěl) a zadruhé ARM je od zavedení Thumb-2 a NEONu jakýsi CISC/RISC hybrid, aniž by jakkoliv utrpěla zpětná kompatilibita (jako trpěla s Itaniem).

Uz i non-Thumb ARM je hustotou kodu dost blizky i386, na rozdil treba od MIPSu, kde mi tataz vec prelozena pro SGI vychazela zhruba 2.5* delsi nez na Intelech.

Navic zapominate ze velkost kodu ovlivnuji spis zapnute optimalizace v kompilatoru (inlining, loop-unrolling/SW-pipelining), nez instrukcni sada. Zrovna treba SW-pipelining zavisi na latencich instrukci konktetni implementace CPU. Takze treba na ARM7 kde je to jedno SW-pipelining kod neprodlouzi, kdezto kdyz nechate optimalizovat pro nejaky novy Cortex s dlouhou pipeline, tak muze dojit k nekolikanasobnemu prodlouzeni kodu --- ale nastesti se to tyka jen hot-spotu, jinde nema cenu takovou optimalizaci zapinat, takze ve vysledku to nebude az tak hrozne.

Ještě mě napadlo, že tady porovnáváme počet tranzistorů u prvních ARMů (CMOS) a 8086 (NMOS). Ve skutečnosti, kdyby byl první ARM realizovaný pomocí NMOS, tak těch tranzistorů má ještě míň (24k?, 22k? - záleží na typu hradel).

Jo, to je dobry potreh. Mozna takhle to Furber myslel kdyz rikal ze ARM-1 ma min transistoru nez Z-80.

Pritom jenom registry by zabraly 6*27*32=5184 transistoru kdyby se pouzila 6-ti transistorova SRAMka. Latche k nim by daly nejmin dalsich 3*27*32=2592 (2* read 1* write port), ale spis jeste vic.

Jen bych dodal, že srovnání v počtu transistorů není úplně jednoduché. Od 486 se v čipu objevuje L1, později L2 a ještě později L3 cache, která počet transistorů výrazně zvyšuje. Zajímavé by bylo srovnat jen počet transistorů v jádře, což ale není jednoduché zjistit.
Navíc tuším u Pentia se z vnějšího CISCu stal vnitřní RISC, což vedlo kompletně ke změně architektury.