Re: přístup na byty v int C

Pátek Listopad 1 16:59:37 CET 2013

Ahoj Riso,

architektura PIC16 nema zasobnik ako taky, cize parametre nejdu predavat
cez stack, tak ako je to pri inych jadrach. Tu je len call a return a mozes
mat vnorenych max. 8x call. Potom nastane pretecenie zasobnika.

Parametre sa tu predavaju tak, ze sa urobi program flow a zisti sa kolko
bytov ram treba na predanie parametrov jednotlivym funkciam a ci sa nahodou
z nich nevolaju aj ine rutiny. Podla toho sa vyhradi v bankach ram pocet
bytov a tam sa normalne parametre ukladaju cez movfw instrukciu. Takze
mozes mat napr. dve rutiny

void fn1(unsigned int Cycles)
void fn2(unsigned char Steps)

a na zasobniku bude vyhradene miesto takto:

premenna             adresa
fn1 na Cycles      .... 1
fn1 na Cycles +1 .... 2

fn2 na Steps       .... 1, kde sa rutiny navzajom nevolaju,
fn2 na Steps       .... 3, pokial sa rutiny volaju navzajom

a potom uz rutina pracuje s fixnymi adresami premennych.

Kompilator ma este jeden typ premnnej a to btemp, co nie je nic ine ako
vyhradenych 4,8,12... bytov v pamatovom bloku, ktory je pristupny vo
vsetkych pamatovych bankach RAM a moze sa na tento blok pozerat ako na "16x
8bitovych registrov". Vacsinou sa to pouziva na ukladanie premennych pri
preruseni, aritmetickych operaciach a pod. Takto to funguje na architekture
PIC16.

PIC18 a PIC16F1xxx su uz takym mixom s roznymi vylepseniami a v podstate sa
da povedat, ze PIC18 je uz parodia na AVR, ktora sa objavila zhruba rok
potom, co prisli norski studenti s AVR...

A.

Dňa 1. novembra 2013 14:26, Richard Kaliciak
<hw.kaliciak na stonline.sk>napísal(-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
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20131101/50a0f290/attachment.htm>