Re: Re: přístup na byty v int C
Andrej Jancura
aj.hwlist na gmail.com
Středa Říjen 30 14:18:41 CET 2013
Ta reklamna hlaska na to, ze je to reklama z Lidlu, tie pocty instrukcii
sedia dost dobre. Mam to vyskusane na viacerych mensich moduloch z cias,
ked som bol este posadnuty a nadseny programovanim a nechapal co je "vyssia
moc". A kedze si spominal, ze nova verzia XC8 generuje mensi kod, bol som
zvedavy na to, ze kolko to je. Ci ma vobec zmysel uvazovat na uprgade alebo
sa na tie pic uplne vykaslat. Co sa mi teda moc nechce, kedze mam s nimi
skusenosti a robia sa aj v bastlicsky prijatelnych puzdrach. Ale nechcem
ziadny flame, ako sa tu rozputal naposledy, ked sme rozoberali plusy a
minusy 16f690...
A.
Dňa 30. októbra 2013 13:54, Jaromir Sukuba <jarin.hw na gmail.com> napísal(-a):
> Ta hlaska je vacsinou blbost a podoba sa na reklamne letaky z lidlu.
> Vedia, ze usetrenie kodu moze byt niekde od 0 do 60%, tak je hlaska
> vzdy - mozete usetrit az 60% kodu. Pri 10k binarke to zahalsi ze mozes
> usetrit 6k, teda vysledna binarka moze mat 4k. Nic zaujimavejsie a
> serioznejsie tam nebyva, ziadna analyza kodu.
>
> Dňa 30. októbra 2013 13:31, Andrej Jancura <aj.hwlist na gmail.com>
> napísal/a:
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/3446e4f1/attachment.htm>
Další informace o konferenci Hw-list