Diskuzní fórum Elektro Bastlírny

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_ píše: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:

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

mihal píše: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?

Ako je deklarovane AT91C_BASE_PMC? Tam asi treba pridat volatile.

rnbw píše:Ako je deklarovane AT91C_BASE_PMC? Tam asi treba pridat volatile.

#define AT91C_BASE_PMC ((AT91PS_PMC) 0xFFFFFC00) // (PMC) Base Address

...už se konflikt připravuje k vyhrocení,
panna bledá dva nožejčky hledá...

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

Ten příklad mi není jasný.

AT91C_BASE_PMC -> PMC_PCER = 1<<AT91C_ID_UDP;

Tady je AT91C_BASE_PMC použito jako ukazatel na nějakou strukturu

#define AT91C_BASE_PMC ((AT91PS_PMC) 0xFFFFFC00)

ale tady je totéž deklarováno jako konstanta.
???