Re: Re: přístup na byty v int C

Andrej Jancura aj.hwlist na gmail.com
Středa Říjen 30 13:31:24 CET 2013


Ahoj,

Dňa 30. októbra 2013 12:17, Jaromir Sukuba <jarin.hw na gmail.com> napísal(-a):

> No vidis, takze ty sa nakoniec vymacknes. Inkrementacia je nieco ine
> ako dekrementacia :-)
>

No vidis, AVR ma vraj implementovane len odcitanie, lebo 2x minus po sebe
je znova plus. Takze rozdiel medzi inkrementom a dekrementom je len
konstanta... :)


> Cvicne som to skusil pre tri rozne 8-bitove  PIC MCU s XC8 1.2
>

Dakujem ti za namahu. Mna osobne by ale zaujimala pri 16f690 ta hlaska, ze
kolko instrukcii z toho kodu sa usetri pri kompilacii s verziou PRO.


>
> 16F690:
> while(i--)
> 0x7CF: GOTO 0x7D3
> 0x7D3: MOVLW 0x1
> 0x7D4: MOVWF __pcstackCOMMON
> 0x7D5: MOVLW 0x0
> 0x7D6: MOVWF 0x7B
> 0x7D7: MOVLW 0x0
> 0x7D8: MOVWF 0x7C
> 0x7D9: MOVLW 0x0
> 0x7DA: MOVWF 0x7D
> 0x7DB: MOVF __pcstackCOMMON, W
> 0x7DC: SUBWF i, F
> 0x7DD: MOVF 0x7B, W
> 0x7DE: BTFSS STATUS, 0x0
> 0x7DF: INCFSZ 0x7B, W
> 0x7E0: GOTO 0x7E2
> 0x7E1: GOTO 0x7E3
> 0x7E2: SUBWF 0x77, F
> 0x7E3: MOVF 0x7C, W
> 0x7E4: BTFSS STATUS, 0x0
> 0x7E5: INCFSZ 0x7C, W
> 0x7E6: GOTO 0x7E8
> 0x7E7: GOTO 0x7E9
> 0x7E8: SUBWF 0x78, F
> 0x7E9: MOVF 0x7D, W
> 0x7EA: BTFSS STATUS, 0x0
> 0x7EB: INCFSZ 0x7D, W
> 0x7EC: GOTO 0x7EE
> 0x7ED: GOTO 0x7EF
> 0x7EE: SUBWF 0x79, F
> 0x7EF: MOVLW 0xFF
> 0x7F0: XORWF 0x79, W
> 0x7F1: BTFSS STATUS, 0x2
> 0x7F2: GOTO 0x7FD
> 0x7F3: MOVLW 0xFF
> 0x7F4: XORWF 0x78, W
> 0x7F5: BTFSS STATUS, 0x2
> 0x7F6: GOTO 0x7FD
> 0x7F7: MOVLW 0xFF
> 0x7F8: XORWF 0x77, W
> 0x7F9: BTFSS STATUS, 0x2
> 0x7FA: GOTO 0x7FD
> 0x7FB: MOVLW 0xFF
> 0x7FC: XORWF i, W
> 0x7FD: BTFSS STATUS, 0x2
> 0x7FE: GOTO 0x7D0
>
>
> 16F1519:
> while(i--)
> 0x7DC: MOVLW 0x1
> 0x7DD: MOVWF __pcstackCOMMON
> 0x7DE: MOVLW 0x0
> 0x7DF: MOVWF 0x7B
> 0x7E0: MOVLW 0x0
> 0x7E1: MOVWF 0x7C
> 0x7E2: MOVLW 0x0
> 0x7E3: MOVWF 0x7D
> 0x7E4: MOVF __pcstackCOMMON, W
> 0x7E5: SUBWF i, F
> 0x7E6: MOVF 0x7B, W
> 0x7E7: SUBWFB 0x77, F
> 0x7E8: MOVF 0x7C, W
> 0x7E9: SUBWFB 0x78, F
> 0x7EA: MOVF 0x7D, W
> 0x7EB: SUBWFB 0x79, F
> 0x7EC: MOVLW 0xFF
> 0x7ED: XORWF 0x79, W
> 0x7EE: BTFSS STATUS, 0x2
> 0x7EF: GOTO 0x7FA
> 0x7F0: MOVLW 0xFF
> 0x7F1: XORWF 0x78, W
> 0x7F2: BTFSS STATUS, 0x2
> 0x7F3: GOTO 0x7FA
> 0x7F4: MOVLW 0xFF
> 0x7F5: XORWF 0x77, W
> 0x7F6: BTFSS STATUS, 0x2
> 0x7F7: GOTO 0x7FA
> 0x7F8: MOVLW 0xFF
> 0x7F9: XORWF i, W
> 0x7FA: BTFSC STATUS, 0x2
> 0x7FB: GOTO 0x7FF
> 0x7FE: GOTO 0x7DC
>
>
> 16F26K22:
> while(i--)
> 0xFFDC: BRA 0xFFE2
> 0xFFE2: DECF i, F, ACCESS
> 0xFFE4: MOVLW 0x0
> 0xFFE6: SUBWFB 0x8, F, ACCESS
> 0xFFE8: SUBWFB 0x9, F, ACCESS
> 0xFFEA: SUBWFB 0xA, F, ACCESS
> 0xFFEC: INCF i, W, ACCESS
> 0xFFEE: BTFSC STATUS, 2, ACCESS
> 0xFFF0: INCF 0x8, W, ACCESS
> 0xFFF2: BTFSC STATUS, 2, ACCESS
> 0xFFF4: INCF 0x9, W, ACCESS
> 0xFFF6: BTFSC STATUS, 2, ACCESS
> 0xFFF8: INCF 0xA, W, ACCESS
> 0xFFFA: BTFSS STATUS, 2, ACCESS
> 0xFFFC: BRA 0xFFDE
>
> Vsimaj si, ako sa zmensuje kod pri pouziti novsieho MCU. A nebude to asi
> nahoda.
> Takze osembitove MCU su dobre aj pre ine ako osembitove a binarne
> operacie (tsss...), ale treba si zvolit nieco z tohto tisicrocia. Oni
> ti Microchipaci nevyrabaju radu PIC18 pre srandu kralikov, asi tusia,
> ze 35 rokov stare jadro PIC16 ma svoje rezervy.
>
>
>
>
> Dňa 30. októbra 2013 11:58, Andrej Jancura <aj.hwlist na gmail.com>
> napísal/a:
> >
> > No ja mam takyto kus kodu pre pic16xxx:
> >
> > void Delay(unsigned long int Cycles)
> >    while(Cycles--)
> >     ;
> >
> > asm:
> >                    movlw    1
> >                    movwf    Delay
> >                    clrf    Delay+1
> >                    clrf    Delay+2
> >                    clrf    Delay+3
> >                    subwf    Delay na Cycles,f
> >                    movf    Delay+1,w
> >                    skipc
> >                    incfsz    Delay+1,w
> >                    subwf    Delay na Cycles+1,f
> >                    movf    Delay+2,w
> >                    skipc
> >                    incfsz    Delay+2,w
> >                    subwf    Delay na Cycles+2,f
> >                    movf    Delay+3,w
> >                    skipc
> >                    incfsz    Delay+3,w
> >                    subwf    Delay na Cycles+3,f
> >                    incf    Delay na Cycles& (0+127),w
> >                    skipnz
> >                    incf    (Delay na Cycles+1)& (0+127),w
> >                    skipnz
> >                    incf    (Delay na Cycles+2)& (0+127),w
> >                    skipnz
> >                    incf    (Delay na Cycles+3)& (0+127),w
> >                    btfsc    3,2
> >                    return
> >                    goto
> >
> > V 1.12 je podla mna ten kod este dlhsi. Pre increment je ta rutina
> podobna.
> >
> > A.
> >
> >
> >
> > Dňa 30. októbra 2013 11:29, Jaromir Sukuba <jarin.hw na gmail.com>
> napísal(-a):
> >
> >> Presvedcil som sa: XC1.12
> >>
> >> 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.
> >> Andy, ako to robis, ze uplne bezne veci u teba skratka nefunguju?
> >> Rozmyslam, ze by som ta zamestnal ako beta-testera.
> >>
> >>
> >>
> >>
> >> Dňa 30. októbra 2013 11:12, Andrej Jancura <aj.hwlist na gmail.com>
> >> napísal/a:
> >> > Ahoj,
> >> >
> >> > nemusis sa hned citit dotknuty vsetkym co napisem. Pozri ja som to
> >> > pochopil
> >> > tak, ze aj ked uniony nie su podla normy a cez pointre mi nikdy takato
> >> > konverzia nechodila, lebo kompilator vrestal, myslim si, ze mozes
> pisat
> >> > kod
> >> > tak, aby si bol podla normy a sucasne vygenerujes optimalny kod v asm.
> >> > Taky
> >> > ako by si ho napisal v pure asm.
> >> >
> >> > Tie konstrukcie si ale musis najst sam a pozriet ako sa co preklada.
> A v
> >> > pripade PicC a XC8 je kazda C konstrukcia generovana inym kodom. Mozes
> >> > sa o
> >> > tom presvedcit napr. ked si das unsigned long int i, a v programe mas
> >> > i++...
> >> > Neviem sice ako posledna xc1.21, ale nejaka 1.12 to generovala takou
> >> > rutinou, kde som prvy krat v zivote skonstatoval, ze neviem pochopit
> co
> >> > ten
> >> > kus asembleru robi. Predchadzajuca verzia kompilatora totiz pouzivala
> >> > klasicky incfsz...
> >> >
> >> > Zial uz som dlho nic s tymto nerobil, pretoze som bol znechuteny tym,
> ze
> >> > aj
> >> > ked som vygeneroval z C kod ako keby bol z asembleru v app. note, aj
> tak
> >> > mi
> >> > to poriadne nechodilo na hw. Avsak medzicasom som prisiel na par
> trikov,
> >> > ale
> >> > to sa zda, ze je cisto hw zalezitost a treba pouzit iny algoritmus
> >> > obsluhy
> >> > hw.
> >> >
> >> > A.
> >> >
> >> >
> >> > Dňa 30. októbra 2013 9:57, Jan Waclawek <konfera na efton.sk>
> napísal(-a):
> >> >
> >> >> Lenze type punning nie je podla normy; resp. z normy priamo vyplyva,
> ze
> >> >> obe
> >> >> metody maju normou nedefinovany vysledok.
> >> >>
> >> >> Ako som bol pisal, ak mas pocit, ze nieco treba mat urcite napisane
> >> >> nejakym
> >> >> sposobom, netreba zbytocne vahat a treba ist do asm. To zase u tych
> >> >> ARMov
> >> >> nie je uplne trivialne, ale u 8-bitov sa to priamo nuka. Uznavam, ze
> >> >> nie
> >> >> kazdy kompilator ma taku uzasnu podporu pre inline asm ako gcc a
> >> >> uznavam,
> >> >> ze u gcc to zase pada na hubu kvoli mizernej dokumentacii...
> >> >>
> >> >> wek
> >> >>
> >> >>
> >> >>
> >> >> ----- Original Message ---------------
> >> >> >Ahoj,
> >> >> >
> >> >> >to si mozes dovolit na tvojej F4... Ale na cipe s 8K-16K instrukcii
> je
> >> >> >kazdy trik dobry. Ono aj ked to pises podla normy, tak sa to da
> >> >> > napisat
> >> >> >rozne, tak aby si mal minimalny vygenerovany kod.
> >> >> >
> >> >> >
> >> >> >2013/10/29 Jan Waclawek <konfera na efton.sk>
> >> >> >
> >> >> >> Ak "sa to napise" tak, ako norma predpisuje, tak na
> optimalizaciach
> >> >> >> nezalezi.
> >> >> >>
> >> >> >> A o to tu ide.
> >> >> >>
> >> >> >> wek
> >> >> >>
> >> >> >>
> >> >> >> ----- Original Message ---------------
> >> >> >> >No ja bych rekl, ze vic zalezi na zapnutych optimalizacich, nez
> jak
> >> >> >> > se
> >> >> >> >to napise...
> >> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> 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
> >> >
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> 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/20131030/ca696f50/attachment.htm>


Další informace o konferenci Hw-list