Mám dotaz na Cčkové programátory. Před časem se jako OT v jiném vlákně řešilo cosi o programování. Zmínila jsem tam, že přítel hledal několik hodin chybu způsobenou optimalizací gcc překladače. Překladač prohodil pořadí příkazů. A
Martin_ napsal(a):
A to "přítel" nezná direktivu _volatile_ ??? Asi ne ...
Znamená to že jde udělat volatile i kód? Jak se to zapíše?
Slovo Volatile se používá při deklaraci globálních proměnných (případně ještě pointrů na ně).
Nařizuje optimizátoru, aby neměnil kód obsahující tuto proměnnou.
Typický příklad je globální proměnná, která se mění v obsluze přerušení.
Ale i bez přerušení hrozí někdy že optimizátor vyřadí kód, např. tuto časovou smyčku FOR:
kód:
int i;
main()
{
for (i=1; i<1000; i++)
;
}
Optimizátoru se zdá, že tento kód "nic nedělá".
Je na úsudku programátora, které proměnné označit jako volatile.
Pokud bychom tedy chtěli mít celý kód "volatile", označíme preventivně jako volatile všechny glob. proměnné.
To je ale špatně, protože tím silně omezíme optimizátor.
To je můj pohled na "volatile", doufám, že se příliš nemýlím.
Abych to konkretizovala, jednalo se na ARMu o zapnutí hodin pro USB, zápis do řídicího registru USB a vypnutí hodin pro USB.
AT91C_BASE_PMC -> PMC_PCER = 1<<AT91C_ID_UDP;
AT91C_BASE_UDP -> UDP_TXVC = AT91C_UDP_TXVDIS;
AT91C_BASE_PMC -> PMC_PCDR = 1<<AT91C_ID_UDP;
C to zoptimalizovalo tak, že prohodilo první dva příkazy. A protože při zápisu do USB musí běžet hodiny, tak to nefungovalo. Jde v tomto konkrétním případě vysvětlit překladači, aby při optimalizaci neprohazoval příkazy?
Prekladac by mal umoznit optimalization level = 0, ak to ani v tomto pripade nepomoze tak bude chyba v prekladaci. Niektore prekladace je mozne konfigurovat na rychlost kodu aj na dlzku. Ak by som postupne nastavoval flagy v jedinom registri, tak sa stavim ze v kode budu nastavene naraz uz pri minimalnej optimalizacii. Uz preto pouzivam zasadne nulovu optimalizaciu. O cakacich sluckach nehovoriac.
Ale ten kod má být rychlý, krátký a funkční. S optimalizací je krátký a rychlý ale nefunguje, bez optimalizace je funkční ale nepoužitelně pomalý a dlouhý. V assembleru lze splnit všechny tři podmínky, ale bylo mi vysvětleno, že assembler je přežitek, tak by mě zajímalo jak ty tři podmínky splnit v Cčku.
Podla mna assembler nieje prezitok. Stale sa najdu aplikacie (vyzera to tak ze aj ta tvoja) kde je najlepsim riesenim... A bude ti to robit presne to, co si naprogramujes a nie to co ti z Cckoveho kodu spravi optimalizer...
Program v C sa este da zrychlit hodinami procesoru no vazne, mam pripad a bezne sa to aj pouziva, kde koli spotrebe bezim na 32kHz, a ked potrebujem rychlost, zapinam DCO na 16mega
V prípade, ked potrebujem mat rozsiahly program v C a urcite jeho casti su kriticke na cas spracovania, tak tie pisem v asm. Pri doslednej analyze situacie na zaciatku navrhu je potrebne volit aj vhodny pamatovy priestor, aby potom nebolo nutne premyslat nad kazdym bytom. Struktura programu ma tak isto velky vplyv na rychlost, treba sa vyvarovat napr. sw emulacie uartu a pod. Asi nie moc vhodny bude C pri programe pre prijem FSK radia, kde zalezi na kazdej us, naopak, asm by som urcite nevolil napr. pri FFT. Ale nakoniec aj tak zalezi hlavne na x-faktore (stabilita zadania, cas,zakaznik).
Program v C sa este da zrychlit hodinami procesoru no vazne, mam pripad a bezne sa to aj pouziva, kde koli spotrebe bezim na 32kHz, a ked potrebujem rychlost, zapinam DCO na 16mega
Aneb, když je program pomalý, potřebujete rychlejší počítač To je rada nad zlato.
To všechno jsou známé obecné věci. Mě by zajímala odpověď toho Martina_ co rejpal do mého přítele, že nezná _volatile_, nebo co na to třeba panové mtajovsky a piitr, když ohrnovali nos nad assemblerem a tvrdili, že v C to je jen o 25% pomalejší/delší. Co vy na to?
Prekladac by mal umoznit optimalization level = 0, ak to ani v tomto pripade nepomoze tak bude chyba v prekladaci.
Překladač to jistě umožňuje, ale optimalizace je přece jedna z nejsilnějších vlastností překladače. Ve Winavr např. může zkrátit kód až třeba na polovinu.
Vzdát se jí je podobné jako strčit do F jedničky motor z trabanta.
V krajním případě bych kritickou část kódu ve formě funkce umístil do zvláštního .c souboru. Pak bych .c soubory kompiloval odděleně, tento bez optimalizace, všechny ostatní s plnou optimalizací.
Je pravda, že tady asi to volatile není moc k čemu napsat. Vidím asi tyto možnosti:
1) To AT91C_BASE_PMC nedefinovat pomocí define, ale jako globální proměnnou s konstantní hodnotou, a tu definovat jako volatile. Nevím ale jistě, že to pomůže, já s tím volatile moc nedělám. Taky ten kód asi nebude tak hezký a rychlý. To bych asi nepreferoval.
2) Do HW registrů zapisovat pomocí speciální fukce, třeba output(addr, value), která bude definována v jiném modulu a ke kódu se pak až přilinkuje. Pak nemá překladač šanci optimalizovat. Tohle bych udělal tehdy, pokud mi nejde o rychlost, ale chci to mít vážně celé v C.
3) Tu část kódu, která píše do HW registrů napsat v assembleru, zbytek v C a mezi tím udělat nějaké rozumné rozhraní. Nějak rozdělit zodpovědnosti. Pak to celé slinkovat. To bych použil, pokud mi jde o tu rychlost. Někdy je to i přehlednější než možnost (2).
Časy uváděny v GMT + 1 hodina Jdi na stránku 1, 2Další
Strana 1 z 2
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.