CPU s jednou instrukci ;).

[Jiri Bezstarosti]

Tady jde spis o to, ze i pro zdanlive tezkopadne resitelne veci se da 
najit snadne reseni pres registry, staci najit spravnou myslenku.

Ano, vyrabet konstantu jen matematickymi a logickymi operacemi muze byt 
trochu delsi a tak zkusim popsat jiny zpusob.

Dejme tomu, ze mam 16b registry. Klidne si dovolim 256 registrum 
pridelit primo cislo (to zase zalezi na delce instrukce, kolik mam 
registru celkem a co si mohu dovolit). Pak do jednoho registru zkopiruju 
pulku bitu konstanty, do druheho druhou pulku konstanty a ze tretiho si 
to vezmu slepene do 16b konstanty. Jsou to 2 instrukce k sestrojeni 
konstanty, coz neni nic hrozneho. Ze si tu konstantu pak nekam prehazuju 
atd., to delam u beznych komercnim MCU taky.

Vsechno je to vzdy jen o jednoduche a nebo slozitejsi myslence ;).

--
Jiri Bezstarosti

Miroslav Sinko napsal(a):

>Trochu sa doplnim. napr. uz tu zmienovane nacitanie 8-bit konstanty do
>registra bude instrukcia dost casto pouzivana. Nech je to len 0.5% zo
>vsetkych instrukcii v _priemernom_ programe. To sa uz oplati na to
>vyhradit samostatnu instrukciu, miesto nacitania nejakeho SFR a
>naslednych operacii, ktore dosiahnu vypocitanie ziadanej konstanty v
>registri (v najjednoduchsom pripade by bolo 256 registrov s
>konstantami). Podobne to bude s dalsimi instrukciami, povedzme call a
>ret. 
>Aby som uzavrel moje (mozno zle) uvahy, myslim si, ze pomer "pocet
>instrukcii"/"vykon _bezneho_ programu" bude lepsi pri viacerych
>instrukciach, ako jednej. Ona ta jedna instrukcia a z toho vyplyvajuca
>nutnost si k niektorym praktickym cinnostiam pripravit data / nasledne
>ich vycitat, bude zvadzat k makram. Makro ako take nie je na zavadu,
>ale fyzicky v CPU si vyziada viac strojovych cyklov a kazde jeho
>pouzitie zaberie viac programovej pamate. Ak su aj toto kriteria pri
>vymyslani LEPSIEHO a DOKONALEJSIEHO procseora, myslim, ze dospejete k
>tomu, ze predsa len bude lepsie niektorym instrukciam vyhradit vlastny
>operacny kod.
>
>miro
>  
>