Re: Re: přístup na byty v int C
Jaromir Sukuba
jarin.hw na gmail.com
Středa Říjen 30 13:54:05 CET 2013
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
>
Další informace o konferenci Hw-list