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 :-)
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.
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.