<div>-Os je optimalizace na velikost ne rychlost.<br/>
<br/>
L.<br/>
--<br/>
Stručně naklofáno na mobilu.<br/><br/>-----Original Message-----<br/>From: Jan Waclawek <konfera@efton.sk><br/>To: HW-news <hw-list@list.hw.cz><br/>Sent: st, 22 Čvc 2015 2:09<br/>Subject: Re: Odpuzovac na hlodavce<br/><br/></div>Tu dobu je nemozne posudit, pretoze to
<br/>
- zavisi od stupna nastavenej optimalizacie
<br/>
- zavisi od inych nastavenych prepinacov
<br/>
- zavisi od verzie kompilatora (vid nizsie)
<br/>
- pouzivate tam funkcie do ktorych nevidim
<br/>
<br/>
Rozdiely mozu byt dramaticke, ano, aj 2x aj viac.
<br/>
<br/>
Na druhej strane, pre Vas je to zistit resp. odhadnu velmi jednoduche -
<br/>
vyhodte ten kus kodu ktory sposobuje premenlive casovanie (t.j. tu kaskadu
<br/>
if-ov s delaymi, na konci slucky) vlozte toggle nejakeho pinu a pozerajte
<br/>
na osciloskope.
<br/>
<br/>
Ak prekladate v tych roznych prostrediach s rovnakymi prepinacmi, rozdiel
<br/>
bude pravdepodobne sposobeny verziou prekladaca. avr-gcc vo vseobecnosti
<br/>
produkuje (produkoval) horsi a horsi kod s kazdou novou verziou az do
<br/>
nejakej verzie 4.7; samozrejme to zavisi od vela faktorov, ale vseobecny
<br/>
trend bol tento. Dovodom je, ze jadro optimalizacii je pre dominantne
<br/>
32-bitove procesory, a nasledky vylepsovania tychto optimalizacii su pre
<br/>
avr casto pesimalizujuce. Pochopitelne sa s novymi verziami opravovali
<br/>
chyby starych, pridavali nove vlastnosti a nove cipy, takze nie je dobre
<br/>
pausalne povedat ze sa treba drzat nejakej konkretnej velmi starej verzie.
<br/>
<br/>
Co sa tyka prepinacov, tak tie, ktorymi sa nastavuje "nahrubo"
<br/>
optimalizacia, vyzeraju jednoducho - -O0 je bez optimalizacie, -O1 az -O3
<br/>
je postupne zvysujuca sa optimalizacia na velkost kodu, -Os je
<br/>
optimalizacia na rychlost. No ale za tymito prepinacmi sa skryva sada
<br/>
inych prepinacov, casto so zlozitou funkcionalitou, navzajom sa
<br/>
ovplyvnujuce, casto zapinajuce prave optimalizacie ktore su pre 32-bitove
<br/>
procesory optimalne ale pre AVR pesimalne. Tych prepinacov je vela -
<br/>
niekolko desiatok, a niektore maju este parametre - takze vyskusat ucinok
<br/>
vsetkych, a najma vsetky ich kombinacie, je prakticky nemozne. No a
<br/>
pochopitelne je ucinok tychto parcialnych optimalizacii zavisly na
<br/>
konkretnom zdrojovom kode. Konkretna skusenost pre AVR je napriklad taka,
<br/>
ze -Os produkuje dost casto mensi kod nez -O3. Ako dodatocny bonus k
<br/>
zlozitosti problematiky, co je to "rychlost", je urcit v skutocnych
<br/>
nesyntetickych programoch velmi, velmi tazke.
<br/>
<br/>
Rovnako nie je jednoduche doporucit nejaku "mikromanipulaciu", ktorou sa
<br/>
prekladac prinuti vygenerovat ekvivalentny ale rychlejsi/mensi kod.
<br/>
Napriklad vo Vasom pripade optimalizator pravdepodobne neuhadne, ze ta
<br/>
sustava shift-or sa da nahradit maskovanim; ba dokonca niektore (prave tie
<br/>
novsie) verzie mali problem optimalizovat aj tie shifty (ktore sa
<br/>
mimochodom daju kaskadovat a ktore sa daju robit ako 8-bitove. Takze ak
<br/>
rucne prepisete ten kod tak aby sa pouzili masky, moze vyjst rychlejsi;
<br/>
toto je vsak ukazkovy priklad toho, ze sa v tom strati ten povodny
<br/>
"algoritmus" resp. ten priamy odkaz na povodne HW riesenie.
<br/>
<br/>
Ja osobne to vsak nemam rad. Su nejake vseobecne pravidla - typu nepouzivat
<br/>
zbytocne velku premennu a nepouzivat zbytocne znamienkove typy (a int je
<br/>
obvykle zbytocne velky a znamienkovy) - ktorymi sa prekladacom da pomoct a
<br/>
tie treba dodrziavat. Ale mikromanipulacia je podla mna v dlhodobom
<br/>
hladisku kontraproduktivna (to je na dlhsiu debatu pivneho charakteru -
<br/>
dojdite, popijeme, podiskutujeme). Ak mate potrebu drzat kontrolu nad
<br/>
niektorym aspektom programu (napr. casovanim), napiste ho v asembleri.
<br/>
Zhodou okolnosti ten vas napisat je velmi jednoduche, mozno este
<br/>
jednoduchsie nez to co ste zbastlili v tom C++duine. Dalsia vec, co by ste
<br/>
kazdopadne mali spravit, je, necasovat delayom ale HW timerom - ten kod
<br/>
pochopitelne musi byt aj tak dostatocne rychly.
<br/>
<br/>
Ja viem, ze som slubil v paralelnom vlakne ze sa z arduinovskeho programu
<br/>
pokusim spravit normalny, ale nemal som na to cas, preto neviem prelozit
<br/>
ani ten Vas. Ale ak niekam date vysledok prekladu - staci elf - tak mozme
<br/>
podebatovat nad disasemblingom trocha podrobnejsie.
<br/>
<br/>
wek
<br/>
<br/>
<br/>
PS. Prosim nepouzivajte html pre pisanie do konfery, a najma ak vkladate
<br/>
zdrojove texty; pozrite, ako to dopadlo:
<br/>
<a href="http://list.hw.cz/pipermail/hw-list/2015-July/478367.html">http://list.hw.cz/pipermail/hw-list/2015-July/478367.html</a>
<br/>
<br/>
<br/>
_______________________________________________
<br/>
HW-list mailing list - sponsored by <a href="http://www.HW.cz">www.HW.cz</a>
<br/>
<a href="mailto:Hw-list@list.hw.cz">Hw-list@list.hw.cz</a>
<br/>
<a href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
<br/>