Názory k článku
Instrukční sada mikroprocesorů ARM

Má cenu se zabývat instrukcemi pro ARM? Při použití jazyka C není potřeba nic řešit a rozdíly mezi například Cortex-M0 a M4 jsou takové, že v Assembleru to je skoro nereálné.

No 16bit ještě možná jo, protože jsem v něm kdysi programoval flash loadery pro mobily a něco málo zpětně rozebral. Ovšem arm mode (32bit) je tak složitej na ruční programming, že je to maximálně pro kompilery. Však arm nikdy nebyl pro ruční programování.

32bit mi naopak prijde jako velice vhodny assembler pro rucni programovani (alespon pro ARM7, kde clovek nemusi resit interlocky aby kod zbytecne necekal, ale da se i na ARM9). Po chvili cviku si clovek na tu symetrii celkem zvykne. Navic je ARM oproti jinym RISC celkem standardni (ma Carry flag, nema zpozdeny skok). Velkou vyhodou je take jednoducha instrukcni sada -- da se to naucit za den.

Naopak Thumb nemam zrovna moc rad, prijde mi ze pri rucnim programovani a dobrem vyuziti barrel shifteru ta vyhoda ve vyssi hustote kodu neni zase tak podstatna (protoze proti ni pusoubi taky dvouadresovost, taky nemuzu pouzivat vsechny registry libovolne ale nizsih 8 a vyssich 8 je oddeleno, coz zpusobuje ze nakonec tech instrukci potrebuju vic takze to bezi pomaleji a neni to ani o mnoho mensi).

Pokud se dostanete do situace, kdy je treba proklepnout, co kompilator vymysli (a ze obcas vymysli), tak je pomerne uzitecne vedet, co ktera instrukce znamena :)

Psát celé programy v ASM je už dneska pasé.
Ale na specifické účely, jako třeba šifrování nebo práce s videem, jsou malé části v ASM významný přínos, také se to hodí na exponované přerušení.

Podle mych zkusenosti je dobre mit alespon povedomi o to, na cem vlastne ten ceckovy program (po prelozeni) pobezi a jake jsou tedy zakladni vlastnosti te ktere architektury.

Napriklad diky existenci bitu Carry (nektere procesory ho nemaji) lze rici, ze asi bude docela jednoducha implementace viceslovni aritmetiky (i kdyz docela pochybuji, ze to nekdo dokaze optimalne napsat v cecku :-), jak se bude cecko chovat ke statickym promennym, jak a zda vubec se bude provadet zarovnavani operandu, jestli je vubec mozne efektivne provadet aritmeticky posun doprava (na 6502 se to muselo hackovat) atd. atd.

On ARM je z tohoto pohledu vlastne docela "mainstreamovy" procesor, ale na nejakem DSP se clovek muze divit, ze treba char vlastne nema osm bitu, ze float/double nejsou podle IEEE 754 atd.

Má smysl umět orientovat se podle mapy s pomocí kompasu, když jsou dnes GPSky? Normální člověk to asi nepotřebuje, u pilota bych to považoval za samozřejmost.

Jestli na podzim proběhne pár pořádných slunečních bouří, tak se možná budeme učit orientovat nejenom v papírových mapách, ale i v mayském kalendáři :-D

Radovane, Radovane, nesýčkuj ...

V pohode, stary Atarka nebo mainframy byly dobre odstineny a ze to nevydrzi dnesni plastovy masinky nebude zadna velka skoda :-)

Stolní PCčka jsou také v plechové škatuli, ale ty dráty co do nich vedou...
No, asi bych měl pro jistotu Didaktika zabalit do alobalu ;-)

ja mel na mysli takovy ty masinky s ulepenym displejem, jejich zniceni by nekdo neprezil :)

Na druhou stranu tyhle mašinky s ulepeným displejem aspoň jedou povětšinou na ARMu a často jsou MS-free. Sice žádnou nemám, ale přesto jim fandím. Myslím, že je fakt už čas na změnu.

to je pravda, wintel se v teto oblasti skutecne nechyta :-)

Asi jsem něco přehlédl, ale jak se bude řešit situace, kdy zavolaný podprogram bude volat další podprogram? Dojde tak přece k přepisu v registru schované původní návratové adresy....?
To ji musím ručně schovávat někam do RAM?

Starému opelíchanému assembleristovi připadá takový procesor dost primitivní. Naposled jsem podobně bez stacku řešil návraty z podprogramů na ADT4000 :-)

Něco o MMU ARMu bude?

Kdyz mate podprogram ktery bude jeste neco volat, tak proste lr registr ulozite na stack (spolu s ostatnimi registry ktere nechcete prepsat) na zacatku toho podprogramu. Na to jsou specialni instrukce LDM/STM, ktere nekem do pameti (indexovane zadanym registrem, zde stack pointerem pro ktery se tradicne vyuziva r13) ulozi seznam registru (podle bitove masky) a pouzijete variantu ktera navic ten stack pointer inkrementuje. Kod pak vypada takto

stmfd sp!, {r3,r4,r5,lr}
.... telo funkce ... zde muzu volat podprogram
ldmfd sp!, {r3,r4,r5,pc}

Vsimete si ze ldm obnovi stejne registry, s vyjimkou lr. Navratovou adresu vlozi primo do pc, cimz se provede navrat z podprogramu.

Taky se to dobre hodi pro tail recurstion elimination. Pokud volat nejakou funkci tesne pred navratem z podprogramu, prelozi to gcc takto:

stmfd sp!, {r3,r4,r5,lr}
... vnitrek funkce ...
ldmfd sp!, {r3,r4,r5,lr}
b poslednifunkce

cimz se zamezi zbytecnemu plytvani mista na zasobniku (pokud jste zvykli z lispu psat cykly pomoci rekurze tak nedojde ke zbytecnemu pouzivani zasobniku).

Tak, tak, aby to švihalo, tak je potřeba mít jen jedno zanoření subrutin.

On ten procesor skutecne je primitivni, je to by design, neni to chyba :-) [neco jako MIPSy v prvnich verzich]

Jinak ten call se resi ruzne, podle povahy problemu. Bud se pres Rx (vetsinou R13) implementuje zasobnik v RAM, podobne jako na jinych procesorech, nebo se u nekterych subrutin preorganizuji registry tak, ze je navratova adresa ulozena do neceho jineho nez LR. Dtto s predavanim parametru - vetsinou pres registry, ktere se v subrutine pres LDM/STM mohou odlozit, ale dobry prekladac se tomu zuby nehty bude vyhybat.

O MMU ARM, SIMD atd. se jeste urcite zminim.

Ten skok s tím odčítáním osmičky mě fakt zaujal. Taková drobnost zpravidla ukazuje na naprosto nekoncepční vývoj produktu. A přitom je na první pohled jasné, že se mýchají interní věci procesoru s externě dodaným kódem, který nemá povinnost tyto interní záležitosti znát. Každému analytikovi, který by takový návrh uviděl, by se v hlavě rozsvítil zářivý vykřičník a měl by sakra velký problém takový systém pustit dál.

Zadna nekoncepcnost. Naopak to meli promyslene aby usetrili incrementor a neztratili pritom 1 takt pri provadeni skoku. Vzhledem k tomu ze offsety pocita assembler je od toho programator celkem odstinen (navic je to zdokumentovane, takze v tom nevidim problem).

Je pravda ze u novych verzi to uz nema puvodni vyznam, ale uprime receno, kdyby dnes nekdo uplne od zacatku navrhoval procesor pro co nejlepsi vykon a nejnizsi spotrebu, tak by stejne zvolil jine instrukce.

... naprosto nekoncepční ... zářivý výkřiční ...
Sorry, ale to je hlod par excellence. Kódování (a odečítání osmičky) snad řeší assembler a ten to ví. Nebo snad píšeš přímo v hexa kódu? A i kdyby, tak jakej je závažnej rozdíl mezi tím od kterýho bodu se počítá výsledná adresa?

Vnitřní strukturu procesoru do značný míry musí znát každej překladač. Každej procesor má svoje speciality.

No ja jsem se nad tim zkousel zamyslet, jak je to vlastne u jinych procesoru, ktere to 'nejak' resi.

Bud se puvodni hodnota PC musi kopirovat pri propagaci instrukce pres pipeline (takze 2 dalsi registry, coz je tak minimalne 512 tranzistoru pri 32bitove sirce, 6 tranzistorech na bunku a pripojeni na sbernici) nebo by se adresa musela jeste jednou propasirovat pres ALU, takze bud dalsi ALU ci alespon
'inkrementator' (xxx tranzistoru) nebo zpozdeni skoku o dalsi takt.

Nakonec je asi ten problem +-8 vyresen docela dobre :-)

A to je na tom ARM jeste dobre! Napriklad puvodni verze nemela branch delay sloty, ktery by lidem mohly plest hlavu, nebyl to ani superskalarni procesor (takovy Pentia I byly dost komplikovany pri parovani instrukci), proste pohodicka a assembler at si tech +-8 vyresi sam; naposledy jsem relativni skoky rucne pocital u PMI-80, ale to bylo z jinych duvodu - programovalo se to primo v hexa kodu :-)

Drobnost - 8080 neměla relativní adresování :-)

Ah jasne, zapominam. Takze to vlastne bylo jednodussi, zadny PIC, pekne si pocitat delky vsech instrukci ;-)

Jojo, zlaty casy, kdy se Z80 programovala primo v hexu :-). Jeste dodnes, kdyby me nekdo vzbudil ve 4 hodiny rano, bych mu mohl odvykladat "F-E-D-C-B-A-9-8-7-6-5-4-3-2-1", jak jsem pred 25ti lety pocital offsety skoku dozadu :-).
Mimochodem, i Z80 pocital skoky od NASLEDUJICI instrukce, takze 18 00 skocil na nasledujici instrukci, takze vlastne nic nedelal. V assembleru se naopak znakem $ mysli adresa samotne instrukce, takze kdyz nekdo napsal JR $+2, prelozilo se to jako 18 00 a nikdo se tomu nedivil.

Jojo, na 8080 i Z80 jsem taky jel v hexa. Dodnes si pamatuju věci jako C3xxxx, CDxxxx, C9, F3, FB, D3xx, DBxx, 3Exx, 21xxxx, EDB0, AF a mnohý další :-) Na assembler jsem přešel až na Amize.

Tyhle drobnosti naopak řeší poměrně rozsáhlé technologické problémy. Výkonnostní penalizace tam není žádná, zatímco úspora komplexity a počtu tranzistorů je zřejmá. S ohledem na to, kolik měl ARM tranzistorů a kolik jich bylo touto "osmičkou" ušetřeno se bavíme už v řádu promile, což je docela slušná úspora. Chápu že dnes, kdy už ani není na ten křemík co přidat a polovina plochy je prázdná, to lidé vnímají jinak.

To tvoje "mychani" mi pripada jako mnohem zarivejsi vykricnik. :D Takovej "analytik" by byl fakt hodne uzitecnej, kdyz by ho zajimaly takovy pic...y, jako format ulozeni relativni adresy v kodu instrukce, uprednostnovany pred usporou mista na chipu a zefektivneni cinnosti obvodu.

Jednoduše lze spočítat, že díky použití 26bitové konstanty lze provést podmíněný či nepodmíněný skok v rozsahu ±64 MB.

Jakto?

A bit na znamnienko si kde nechal???? Či to ten procak vytuší kam Ty chceš skočiť?

jejda pardon, nepřemýšlím.. :-)

Tady je zajimave video, ktere s ARM souvisi: http://www.youtube.com/watch?v=VK5AZrg3ZD8

Cloveku je smutno, kdyz vzpomina na tu dobu, kdy se tady v Evrope jeste neco opravdu delalo a nebyli tolik premnozeni humanitni zvanilove...Mit tak moznost prenest se v case zpatky....

Dik za video. Treba jeste bude lip ;-)