přístup na byty v int C

[Jaroslav Buchta]

Zatimco tady bude ulozena kde??? ;-)

Kdyz uz by to melo pro pokus fungovat, tak takto:

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

}


Dne 1.11.2013 14:26, Richard Kaliciak napsal(a):
> 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
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list