[BETA] 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:

Kód: Vybrat vše

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

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

Je hezké že ses přemohl
napsat krátkou ódu
lepší kdybys pomohl
rozchodit kus kódu

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