C nebo ASM?

[Jan Waclawek]

>optimalizovat preklad z C do ASM je napr. pre procesory CISC dost 
>problem, napr. ako donutit prekladac pre Z80, aby pouzil instrukciu 
>LDIR, ak mu to predtym v C nepredzujem (=myslim tym vhodny zapis v C, 
>napr --count namiesto count--)? Alebo R8C instrukciu RMPA (Repeat 
>MultiPle and Addition)? (Tu sa to vyriesilo makrom.)
>Potom sa nemozeme cudovat, ze sa po prelozeni do ASM kazdy index znovu 
>pocita.


No, ono to nie je nemozne, ale je to mimoriadne pracne.

V podstate musi optimalizator (resp. ten kto ho pise) odhadnut zamer programatora, a "upravit" ten zapis tak, aby "sadol" na ten hardware; pritom si vsak musi dat pozor na rozne vedlajsie efekty.

Napr. casto sa pise, ze je vyhodnejsie 

for (i = 32; --i; ) {
  [...]
}

nez "standardny" zapis

for (i = 0; i < 32; i++) {
  [...]
}

pretoze ten prvy sa da prelozit bud s pouzitim ekvivalentu djnz u '51 (PIC ma tiez nieco take), alebo ak aj take nie je, tak dekrement casto automaticky nastavi flag zero, takze netreba robit porovnanie.

Avsak kedze sa jedna o "standardny" (casto pouzivany) zapis, niektore (tusim novsi Keil - ako vravim, nemam ho tu, takze nemozem demonstrovat) prekladace toto rozoznaju, a "upravia" ten druhy zapis na ten prvy. Musia to vsak robit opatrne, napriklad aj ked sa i v tele cyklu priamo nepouzije, ale ak je napriklad v tele pouzity break, a i je potom pouzite niekde za cyklom, tak ten "prepis" to vsetko musi zohladnit.

Takychto roznych optimalizacii sa da navymyslat hafo, ale ako vravim, je to hrozne pracne implementovat, lebo sa to musi robit od pripadu k pripadu.

Ako vravi mantra open-source hnutia, vyhodou open-source je, ze si to mozes spravit sam (a co nepovedia, je, ze si to obvykle musis spravit sam... ;-) )

wek