Vlákno názorů k článku Instrukční sada mikroprocesorů ARM od ondra.novacisko.cz - Ten skok s tím odčítáním osmičky mě fakt...
-
ondra.novacisko.cz (neregistrovaný)
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.
-
klusacek (neregistrovaný)
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.
-
zimiston (neregistrovaný)
... 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.
-
Pavel TišnovskýZlatý podporovatelNo 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 :-)
-
Pavel TišnovskýZlatý podporovatel
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. -
Karel (neregistrovaný)
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.
-
homunculus (neregistrovaný)
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.
ČLÁNKY DO MAILU