> Natomiast ja bardzo chętnie chciałbym takie zadanie zobaczyć napisane
> przez Ciebie w asm, o które proszę już od pół roku, założenia do
> kodu:
> - obsługa pendrive usb
> - obsługa vfat
> - sortowanie 5000 liczb ze wskazanego pliku
> - sensowny czas wykonania (krótki timetomarket) - powiedzmy tydzień
>
> Na marginesie, do czego sensownego może się akurat przydać sortowanie
> w 8bitowym mcu 5000 liczb... pachnie mi to znowu jak nieekonomiczne
> użycie mcu do realizacji danego zadania.
W tym poście mamy:
2) ciągłą próbę narzucenia komuś pracy za darmo z perspektywą nagrody w
postaci potępienia.
3) wysnucie SWOJEGO pomysłu, narzucanie go INNEMU, a potem potępienie za
głupotę.

ad.2)
Już Ci napisałem delikatnie, że musisz o to POPROSIĆ.
Nie wiem jak się to rozumie w Twoim środowisku, ale Ty napisałeś: Bardzo
proszę.
No to chyba dodam, że musisz jeszcze za to zapłacić, bo uważasz, że to
trudne dla Ciebie.
Więc jeżeli Cię stać, to złóż w końcu tę ofertę.
Ja nie tworzę zazwyczaj dobrego kodu dla studentów na życzenie.
Pisanie w asm nie jest dla każdego.
Jeśli nie umiesz - musisz płacić.
Ja mam na utrzymaniu rodzinę i nie mogę sobie pozwolić na poświęcenie 1
tygodnia na to tylko, żeby udowodnić,
że umiem zrobić coś co 10 lat temu już zostało zrobione.
ad. 3) Jakbyś przeczytał mój post, a w szczególności nagłówek do procedury w
asm,
masz tam napisaną uwagę co do rozsądności tej procedury na procesory
8-bitowe.
No, ale Ty nawet nie zajrzałeś do kodu w asm.
Oj nieładnie...
S.

do góry

W dniu 2014-04-05 11:10, jacek pozniak pisze:
> 4. AVR-GCC na atmega32 -O2 (nie znam jeszcze dokładnie avr-gcc i jego opcji)
> 376 ROM, 37 RAM

Nie znam kompilatorów PICowych, ale dla AVR-GCC zamiast -O2 daj -Os i
napisz wyniki. No i która to wersja gcc?

--
Michał

do góry

Michał Lankosz wrote:

> W dniu 2014-04-05 11:10, jacek pozniak pisze:
>> 4. AVR-GCC na atmega32 -O2 (nie znam jeszcze dokładnie avr-gcc i jego
>> opcji) 376 ROM, 37 RAM
>
> Nie znam kompilatorów PICowych, ale dla AVR-GCC zamiast -O2 daj -Os i
> napisz wyniki. No i która to wersja gcc?
>
skrypt:
avr-gcc -Wall -Os -mmcu=atmega32 -c main5.c
avr-gcc -Wall -Os -mmcu=atmega32 -o main5.bin main5.o
avr-objcopy -j .text -j .data -O ihex main5.bin main5.hex
avr-objdump -S main5.bin > main5.lst
avr-size main5.bin

wynik:

text data bss dec hex filename
376 2 35 413 19d main5.bin


avr-gcc (GCC) 4.3.4

jp

do góry

> 1. Kompilator HiTech 8.05PL2 -O -Zg, procesor pic16f876A:
> 149 words(słów, nie bajtów) ROM, 38 bytes RAM
> bez funkcji zlicz(), odpowiednio 54 słów ROM, 35 RAM
>
> 2. Kompilator HiTech 9.63PL2 --opt=ALL , procesor pic18f252:
> 284 bytes ROM, 37 RAM
> bez funkcji zlicz(),75 bytes ROM, 15 bytes RAM
>
> 3. Kompilator XC8, ver 1.3 --opt=ALL (60-dniowa) procesor pic18f252: nie
> wiem do końca, ćzy jest właczone MODE PRO niby w ciągu 60 dni powinno być
> właczone ale coś kod zbyt duży wychodzi):
> 606 bytes ROM, 43 RAM
> bez funkcji zlicz() 160 ROM, 35 RAM
>
> 4. AVR-GCC na atmega32 -O2 (nie znam jeszcze dokładnie avr-gcc i jego
opcji)
> 376 ROM, 37 RAM
> bez funkcji zlicz() 222 ROM, 37 RAM
>
> Wśród PICów jaki widać zwycięzcą jest 8.05 na PIC16.
>
> jp
Dzięki.
Mam mieszane uczucia.
Napracowałeś się, przekompilowałeś i mamy fajne dane.
Teraz tak.
Ten PIC, który wybrałeś dla pkt.1 to 16F, a nie 18F.
Różnica jest taka, że on ma 14bitów długość rozkazu, więc tam w bajtach nie
mozna porównywać.
Słusznie napisałeś, że po kompilacji ma 149 _słów_.
Mój w ASM ma 71 słów na 18F.
na 16F miałby o 10 słów więcej, gdyż 16F nie ma rozkazów LFSR,MOVFF i NEGF.
Czyli 81 słów vs. 149 słów, czyli współczynnik C/ASM=1,8.

Całkiem nieźle, jeśli chodzi o nadmiarowość kodu.
Jednak jak powiedziałem - nie mierzyłem czasu, więc nie są te badania
obiektywne,
co do czasu wykonywania.
Ja podałem ok. 6x wolniejszy, ale to tylko szacunek.
Podaj może ilość rozkazów w głównej pętli sortującej, lub umieść kod to
policzymy.
S.

do góry

On Sat, 5 Apr 2014 11:10:49 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> 3) wysnucie SWOJEGO pomysłu, narzucanie go INNEMU, a potem
potępienie za
> głupotę.

Nie wiem skąd takie wnioski wyciągasz, nic bardziej mylnego.


> Już Ci napisałem delikatnie, że musisz o to POPROSIĆ.

Słowo "proszę" padało z mojej strony za każdym razem. Nie wiem, mam
paść na kolana albo kupić kwiaty? ;) Naprawdę jestem ciekaw ile czasu
Ci to zajmie, jakie problemy będziesz miał podczas implementacji i
jak sobie z nimi poradzisz i jakie wnioski wyciągniesz po realizacji
projektu. Uważam, że jest to bardzo świetny pomysł na pewien proof
of concept zrealizowany w asm. Jako programista asm, krytukujący
(całkiem sensownie zresztą) wady kompilatory języków "wyższego
poziomu" powinieneś dać przykład realizacją właśnie takiego projektu.
A Ty zamiast rzetelnej dyskusji robisz za każdym razem focha,
propozycję odbierasz jako podpuszczanie a nawet atak, z góry
zakaładając, że chce Cię wprowadzić na jakaś minę. A uwagi typu
"musisz mi za to zapłacić" w czasach powszechnego i modnego "open
source'a" uważam za słabe, nie wspominając zupełnie o tym, że to
klasyczny unik typu "nie bo nie", "chciałbyś", "musisz o to
poprosić", "nie będę zajmował się pierdołami" itp.

--
Marek

do góry

> 5) Po włączeniu optymalizacji "Enable on" kod zmniejszył się do 342 bajtów
> i w ten sposób współczynnik ilości bajtów C vs. ASM wyniósł: 2,67.
> Główna pętla zwiększyła się ze 121instrukcji na 182!
> Przypominam: w asm 20 instrukcji.
> Możliwe, że ma to swoje umotywowanie czasowe, ale trudno mi sobie je
> wytłumaczyć,
> skoro da się to ze spokojem przeprowadzić w 20 instrukcjach, a niech
będzie,
> że i w 40,
> jeśli jakiś student by się pokusił o nieoptymalne napisanie kodu.
> Ale 182 to już gruba przesada.
Tutaj muszę sprostować.
Oczywiście 182 bajty. Nie instrukcje.
No i dodatkowo okazało się, że jest jeszcze więcej, bo coś około 218 bajtów
W każdym razie, w poniższej pętli jest zawartych 94 instrukcji ASM 18F,
co odpowiada 20 instrukcjom w kodzie pisanym bezpośrednio w ASM.

for(i = n-1 ; i >= 0 ; --i)
{
j=--LICZV[VDIOD[i]]; // aktualizacja LICZV
VDOUT[j] = VDIOD[i]; //wstawienie elementu na odpowiednią pozycję
ADRDOUT[j][0] = ADRDIOD[i][0]; // sortowanie adresów
ADRDOUT[j][1] = ADRDIOD[i][1]; // sortowanie adresów
}

Przepraszam, za pomyłkę.
S.

do góry

Sylwester Łazar wrote:

>> 1. Kompilator HiTech 8.05PL2 -O -Zg, procesor pic16f876A:
>> 149 words(słów, nie bajtów) ROM, 38 bytes RAM
>> bez funkcji zlicz(), odpowiednio 54 słów ROM, 35 RAM
>>
> Słusznie napisałeś, że po kompilacji ma 149 _słów_.
> Mój w ASM ma 71 słów na 18F.
> na 16F miałby o 10 słów więcej, gdyż 16F nie ma rozkazów LFSR,MOVFF i
> NEGF. Czyli 81 słów vs. 149 słów, czyli współczynnik C/ASM=1,8.
>
Podaj proszę ile ma Twoja funkcja zlicz() w ASM napisana, ponieważ podałem
wynik kompilacji z i bez niej. Kompilator pewnie dorzuca jakiś extra kod
jako startup.obj.

> Całkiem nieźle, jeśli chodzi o nadmiarowość kodu.
> Jednak jak powiedziałem - nie mierzyłem czasu, więc nie są te badania
> obiektywne,
> co do czasu wykonywania.
> Ja podałem ok. 6x wolniejszy, ale to tylko szacunek.
> Podaj może ilość rozkazów w głównej pętli sortującej, lub umieść kod to
> policzymy.
> S.
Ja jedynie mogę wklaić wynik kompilacji z opcją -S:
global ?a_zlicz
global _ADRDIOD
global _ADRDOUT
global _LICZV
global _VDIOD
global _VDOUT
global _k
global _main
signat _main,88
FNCALL _main,_zlicz
global _n
global _zlicz
signat _zlicz,88
FNSIZE _zlicz,2,0
global clear_bank0
global start
global used_btemp0
processor 16F876A
psect __Z08170RS_,global
psect text0,local,class=CODE,delta=2
psect text1,local,class=CODE,delta=2
psect strings,global,class=STRING,delta=2
psect const1,local,class=CONST,delta=2
psect const2,local,class=CONST,delta=2
psect rbss_0,global,class=BANK0,space=1
psect temp,global,ovrld,class=BANK0,space=1
file "C:\users\jacek\Temp\_8.AAB"


psect __Z08170RS_

psect text0
_main
;main5.c: 16: VDIOD[0]=1;
bcf 3,5
bcf 3,6 ;carry unused
clrf _VDIOD
incf _VDIOD
;main5.c: 17: VDIOD[1]=2;
movlw 2
movwf _VDIOD+1
;main5.c: 18: VDIOD[2]=6;
movlw 6
movwf _VDIOD+2
;main5.c: 19: VDIOD[3]=4;
movlw 4
movwf _VDIOD+3
;main5.c: 20: VDIOD[4]=3;
movlw 3
movwf _VDIOD+4
;main5.c: 21: ADRDIOD[0][0]=1;
clrf _ADRDIOD
incf _ADRDIOD
;main5.c: 22: ADRDIOD[0][1]=0;
clrf _ADRDIOD+1
;main5.c: 23: ADRDIOD[1][0]=1;
clrf _ADRDIOD+2
incf _ADRDIOD+2
;main5.c: 24: ADRDIOD[1][1]=1;
clrf _ADRDIOD+3
incf _ADRDIOD+3
;main5.c: 25: ADRDIOD[2][0]=1;
clrf _ADRDIOD+4
incf _ADRDIOD+4
;main5.c: 26: ADRDIOD[2][1]=2;
movlw 2
movwf _ADRDIOD+5
;main5.c: 27: ADRDIOD[3][0]=2;
movwf _ADRDIOD+6
;main5.c: 28: ADRDIOD[3][1]=0;
clrf _ADRDIOD+7
;main5.c: 29: ADRDIOD[4][0]=2;
movwf _ADRDIOD+8
;main5.c: 30: ADRDIOD[4][1]=1;
clrf _ADRDIOD+9
incf _ADRDIOD+9
;main5.c: 32: zlicz();
fcall _zlicz
;main5.c: 35: }
ljmp start

psect text1
_zlicz
; _j assigned to ?a_zlicz+0
_zlicz$j set ?a_zlicz
; _i assigned to ?a_zlicz+1
_zlicz$i set ?a_zlicz+1
;main5.c: 38: char i;
clrf 3 ;select bank 0
clrf ?a_zlicz+1
goto l6
l3
movf ?a_zlicz+1,w
addlw _LICZV
movwf 4
bcf 3,7
clrf 0
incf ?a_zlicz+1
l6
movlw 7
subwf ?a_zlicz+1,w
btfss 3,0
goto l3
;main5.c: 42: for(i=0;i<n;++i) ++LICZV[VDIOD[i]];
clrf ?a_zlicz+1
l10
movlw 5
subwf ?a_zlicz+1,w
btfsc 3,0
goto l8
movf ?a_zlicz+1,w
addlw _VDIOD
movwf 4
bcf 3,7
movf 0,w
addlw _LICZV
movwf 4
incf 0
incf ?a_zlicz+1
goto l10
l8
;main5.c: 43: for(i=1;i<k;++i) LICZV[i]+=LICZV[i-1];
clrf ?a_zlicz+1
L1
incf ?a_zlicz+1
movlw 7
subwf ?a_zlicz+1,w
btfsc 3,0
goto l12
decf ?a_zlicz+1,w
addlw _LICZV
movwf 4
bcf 3,7
movf 0,w
movwf btemp
movf ?a_zlicz+1,w
addlw _LICZV
movwf 4
movf btemp,w
addwf 0
goto L1
l12
;main5.c: 44: for(i = n-1 ; i >= 0 ; --i)
movlw 4
movwf ?a_zlicz+1
l15
;main5.c: 45: {
;main5.c: 46: j=--LICZV[VDIOD[i]];
movf ?a_zlicz+1,w
addlw _VDIOD
movwf 4
bcf 3,7
movf 0,w
addlw _LICZV
movwf 4
decf 0
movf 0,w
movwf ?a_zlicz
;main5.c: 47: VDOUT[j] = VDIOD[i];
movf ?a_zlicz+1,w
addlw _VDIOD
movwf 4
movf 0,w
movwf btemp
movf ?a_zlicz,w
addlw _VDOUT
movwf 4
movf btemp,w
movwf 0
;main5.c: 48: ADRDOUT[j][0]=ADRDIOD[i][0];
movf ?a_zlicz+1,w
addwf ?a_zlicz+1,w
addlw _ADRDIOD
movwf 4
movf 0,w
movwf btemp
movf ?a_zlicz,w
addwf ?a_zlicz,w
addlw _ADRDOUT
movwf 4
movf btemp,w
movwf 0
;main5.c: 49: ADRDOUT[j][1]=ADRDIOD[i][1];
bsf 3,0
rlf ?a_zlicz+1,w
addlw _ADRDIOD
movwf 4
movf 0,w
movwf btemp
bsf 3,0
rlf ?a_zlicz,w
addlw _ADRDOUT
movwf 4
movf btemp,w
movwf 0
;main5.c: 50: }
decf ?a_zlicz+1
goto l15

psect const1
addwf 2
_k
retlw 7

psect const2
addwf 2
_n
retlw 5

psect rbss_0
_LICZV
ds 5
_VDIOD
ds 5
_VDOUT
ds 5
_ADRDIOD
ds 10
_ADRDOUT
ds 10

psect temp
btemp
ds 1

do góry

> "musisz mi za to zapłacić" w czasach powszechnego i modnego "open
> source'a" uważam za słabe, nie wspominając zupełnie o tym, że to
> klasyczny unik typu "nie bo nie", "chciałbyś", "musisz o to
> poprosić", "nie będę zajmował się pierdołami" itp.
>
> --
> Marek
Ja tylko napisałem: "musisz o to poprosić"
Te słowa:
"nie bo nie", "chciałbyś", oraz "nie będę zajmował się pierdołami" itp.
siedzą w Twojej głowie.

Ale nie chcem z Tobą dyskutować.
Nie, że to bezowocne, bo zauważam, że starasz się być obiektywny, ale
po prostu Ty nie zrobiłęś takiego porównania, poświęcając swój czas i
pisząc:
a) w ASM
b) w C

Ja to zrobiłem, wyciągnąłem wnioski i podzieliłem się FAKTAMI.

I to masz za darmo. Myślę, że to przyda się innym, a może i Tobie.
Jeśli uważasz, że test który zrobiłem jest głupi, no to mi przykro,
ale nie będę nad tym ubolewał.
S.

do góry

On Sat, 05 Apr 2014 11:10:32 +0200, jacek pozniak
<j...@f...pl> wrote:
> To ja podam wyniki kompilacji Twojego kodu:

Mam wrażenie, że testujący założyli, że proponowany kod w C został
napisany maksymalnie optymalnie albo kompilator niczym wróżka wywróży
sobie co autor chciał zrobić i wygeneruje do tego jak najbardziej
krótki kod :-). Pomijam zupełnie, że kompilujecie "pierdulamenty"
(jakby powiedział Stachu) przez co programiści w asm mogli używać to
jako argument za wyższością asm nad C.

--
Marek

do góry

> Podaj proszę ile ma Twoja funkcja zlicz() w ASM napisana, ponieważ podałem
> wynik kompilacji z i bez niej. Kompilator pewnie dorzuca jakiś extra kod
> jako startup.obj.
U mnie w programi pisanym w ASM liczba instrukcji wynosi: 57
Instrukcje w głównej pętli sortującej: 20
Są 4 pętle, ale chodzi o tę ostatnią.
Wydaje mi się ona najtrudniejsza dla kompilatora.
Ale w innych, jak w tej pierwszej - samo zerowanie też mój kompilator C18
robi głupoty.

A teraz postaram się znaleźć i policzyć instrukcje w głównej pętli
sortującej, w tym co ogłosiłeś po kompilacji.

S.

do góry