přístup na byty v int C

[Richard Kaliciak]

Ahoj Andy,

este sa vratim k tomu tvojmu prikladu:

void Delay(unsigned long int Cycles)
   while(Cycles--)
    ;

nebude to tym, ze ta premenna Cycles je ulozena v zasobniku? Skus ju
definovat lokalne, napr.

void Delay(unsigned long int Cycles)
{ unsigned long int lCycles;
lCycles = Cycles;
  while(lCycles--)
    ;

}

Riso.

Am 31.10.2013 11:28, schrieb Andrej Jancura:
> Dobry den,
>
> starsie verzie prekladaju i++ tak, ze tam je skutocne incfsz a cela
> konstrukcia ma 8 instrukcii a to na 35 rocnej architekture PIC16. Cize
> tak ako ste to odhadol, ten princip. Preco novsie verzie pouzivaju tu
> sialenu konstrukciu neviem, ale da sa vytusit, ze za tym mozu byt
> rozne dovody. Ono je aj tak celkom zaujimave filozofovanie, preco ten
> kompilator negeneruje najoptimalnejsi kod, a to aj v platenej verzii.
> Rozoberat to zbytocne nechcem, lebo problem pristupu k typu int cez
> byty sa tu rozoberal uz aspon tri krat a vzdy sme skoncili pri
> kompilatore C... A poznamkami preco je PIC16 na nic. Tym nechcem
> povedat, ze novsie cipy nie su dobre, ale mozu byt aj ine prakticke
> dovody, preco robit so zabehnutymi typmi.
>
> Tymto by som rad tuto diskusiu z mojej strany uzavrel.
>
> A.
>
>
> Dňa 31. októbra 2013 0:19, Radek Benedikt <benedikt na lphard.cz
> <mailto:benedikt na lphard.cz>> napísal(-a):
>
>     > unsigned long i;
>     > ...
>     > i++;
>     >
>     > 0xFFEA: MOVLW 0x1
>     > 0xFFEC: ADDWF i, F, ACCESS
>     > 0xFFEE: MOVLW 0x0
>     > 0xFFF0: ADDWFC 0x8, F, ACCESS
>     > 0xFFF2: MOVLW 0x0
>     > 0xFFF4: ADDWFC 0x9, F, ACCESS
>     > 0xFFF6: MOVLW 0x0
>     > 0xFFF8: ADDWFC 0xA, F, ACCESS
>     >
>     > Cize celkom pochopitelny kus "assembleru". Nulovanie W po kazdej
>     > inkrementacii je predpokladam dan za free verziu kompilatora -
>     pouziva
>     > sa vseobecne pripocitanie 32-bitovej konstanty k premennej, bez
>     ohladu
>     > na to, ze jedno z nich je skratka jednotka.
>
>     Drobne upresneni naokraj:
>     Ta jednotka je taky 32bitova, ono to neni zas tak nebezne,
>     pricitat 0 +
>     carry k casti promenne. Pravda, sice je obcas videt preskoc
>     nasledujici
>     instrukci(e), kdyz neni prenos a tou nasledujici instrukci je
>     inkrement
>     casti promenne. Opravuji se, dost (vetsina ?) procesoru
>     nenastavuje pri
>     inkrementu prenos a protoze se pricita jednicka k vicebitove promenne,
>     tak je mozne testovat byte na nulu. Takze preskoc nasledujici
>     instrukci(e) neni-li nula. A to celkem trikrat, takze to nebude kratsi
>     nez priklad nahore. A tusim ze to nebude na PICu ani rychlejsi. To by
>     musel mit podmineny skok, ne jen preskok.
>
>     Radek (benedikt2hw.cz <http://benedikt2hw.cz>)
>
>
>     _______________________________________________
>     HW-list mailing list  -  sponsored by www.HW.cz <http://www.HW.cz>
>     Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>     http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list