Kod wynikowy w Bascomie kontra FASTAVR.

amok67 · Postautor: **amok67** » 2 lis 2006, o 21:34

Witam.
Zainstalowałem demo FASTAVR (basic dla avr'ów), (http://www.fastavr.com/)
i porównałem 2 proste programy.

'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
'1.program dla BASCOM:
$regfile = "2313def.dat"
$crystal = 10000000
Config Portb = Output

Do
Shift Portb , Left
Loop
End
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
'2.program dla FASTAVR:
$Device= 2313
$Stack = 32
$Clock = 10 '10MHz

DDRB=&hff
Dim tmp As Byte
tmp=&B11111110

Do
Shift(Left, 1, tmp)
Loop
'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

KOMPILUJEMY...

hex po kompilacji w BASCOM: (324 bajty)

:100000000AC018951895189518951895189518956B
:100010001895189518958FED8DBFC0ECE8EB4E2E16
:10002000DD275D2EEEE7F0E0A0E6B0E088278D93B7
:100030003197E9F766248FEF87BB91E088B3BB2740
:10004000A8E10DD088BBF9CFF894FFCF3197F1F735
:100050000895689462F80895E89462F808959030DD
:0E00600029F08C91880F9A95E9F78C930895FA
:00000001FF

hex dla kompilacji FASTAVR: (112 bajtów)

:020000020000FC
:10000000CFEDCDBFA097EFEFE7BBEFEFE093600040
:0C001000E0916000EE0FE0936000FACF7A
:00000001FF

I co wy na to?

[ Dodano: 02-11-2006, 21:38 ]
Sorry, oto poprawny prog.Dla FASTAVR.

$Device= 2313
$Stack = 32
$Clock = 10
DDRB=&hff
PORTB=&b00000001

Do
Shift(Left, 1, PORTB)
Loop

hex po kompilacji:
(96 bajtów)
:020000020000FC
:10000000CFEDCDBFA097EFEFE7BBEFEFE093600040
:0C001000E0916000EE0FE0936000FACF7A
:00000001FF

[ Dodano: 02-11-2006, 21:42 ]
Raz jeszcze sorry,oto poprawny txt po kompilacji w fastavr:

:020000020000FC
:10000000CFEDCDBFA097EFEFE7BBE1E0E8BBE8B3F2
:04001000EE0FFDCF23
:00000001FF

Fredy · Postautor: **Fredy** » 2 lis 2006, o 22:09

ja zauważyłem że niegospodarność pamięci w Bascomie dotyczy głównie małych programów. Im większy program tym jest lepiej. Porównaj zatem jakiś większy program zajmujący większa pamięć.
Czy ten kompilator "fastavr" ma jakąś dokumentacje?

amok67 · Postautor: **amok67** » 2 lis 2006, o 22:41

Przy większych programach nie jest lepiej.
A przy print - porażka zupełna

Dokumentacja na www.fastavr.com

pajaczek · Postautor: **pajaczek** » 3 lis 2006, o 00:09

Jaki stad wniosek ??

Zacznij pisac w ASM

amok67 · Postautor: **amok67** » 3 lis 2006, o 00:19

Co ty ciągle z tym asm?Jesteś na prowizji?Poza tym to TY masz wyciągnąć wniosek.

szymel · Postautor: **szymel** » 3 lis 2006, o 14:23

I co wy na to?

Strasznie rozrzutny ten FastAVR

Spróbuj przebić C - AVR-GCC:
Listing

Kod: Zaznacz cały

#include <avr/io.h>
void main(void) __attribute__ ((naked));
void main(void)
{
DDRB=0xFE;
PORTB=0x01;
while(1) PORTB<<=1;
}

plik.lss

Kod: Zaznacz cały


                  CONTENTS, READONLY, DEBUGGING
Disassembly of section .text:

00000000 <main>:
#include <avr/io.h>
void main(void) __attribute__ ((naked));
void main(void)
{
DDRB=0xFE;
   0:	8e ef       	ldi	r24, 0xFE	; 254
   2:	87 bb       	out	0x17, r24	; 23
PORTB=0x01;
   4:	81 e0       	ldi	r24, 0x01	; 1
   6:	88 bb       	out	0x18, r24	; 24
while(1) PORTB<<=1;
   8:	88 b3       	in	r24, 0x18	; 24
   a:	88 0f       	add	r24, r24
   c:	fc cf       	rjmp	.-8      	; 0x6 <__zero_reg__+0x5>

no i plik.hex

Kod: Zaznacz cały

:0E0000008EEF87BB81E088BB88B3880FFCCFF2
:00000001FF

Opcja kompilatora -Os , a linkera -nostdlib.

Piotrek
PS
A ten ostatni *.hex , który wkleiłeś , jest do ... bani

Kod: Zaznacz cały

	  ; Atmel AVR Disassembler v1.30
	  ;
         .cseg
         .org	0

          ldi    YL, 0xDF     ; 0000 EDCF
          out    SPL, YL      ; 0001 BFCD
          sbiw   YL, 0x20     ; 0002 97A0
          ldi    ZL, 0xFF     ; 0003 EFEF
          out    DDRB, ZL     ; 0004 BBE7
          ldi    ZL, 0x01     ; 0005 E0E1
          out    PORTB, ZL    ; 0006 BBE8
avr0007:  in     ZL, PORTB    ; 0007 B3E8
          lsl    ZL           ; 0008 0FEE
          rjmp   avr0007      ; 0009 CFFD
          nop                 ; 000A 0000

         .exit

pajaczek · Postautor: **pajaczek** » 3 lis 2006, o 16:55

Co ty ciągle z tym asm?Jesteś na prowizji?Poza tym to TY masz wyciągnąć wniosek.

Pewnie za na prowizji... dostaje 102% ceny...

102% od 0, ile to bedzie...

amok67 · Postautor: **amok67** » 3 lis 2006, o 16:58

"Strasznie rozrzutny ten FastAVR
Spróbuj przebić C - AVR-GCC:..."

Cholera, jestem pod wrażeniem.Chyba zamknę już temat...

szymel · Postautor: **szymel** » 3 lis 2006, o 20:11

Cholera, jestem pod wrażeniem.Chyba zamknę już temat...

Hola hola , nie tak szybko mospanie

Nie wiem co masz za Bascoma , bo wersja 1.11.8.3 generuje kod wynikowy - dla przytoczonego przez Ciebie na początku kodu - o wielkości 104 bajtów , więc skąd te 324

I już na koniec lekko zmodyfikowany listing w C , generuje 12 bajtów kodu wynikowego , którego nie da się "spłodzić" lepiej , nawet w ... assemblerze

Kod: Zaznacz cały

Disassembly of section .text:

00000000 <main>:
#include <avr/io.h>
void main(void) __attribute__ ((naked));
void main(void)
{unsigned char x=1;
   0:	91 e0       	ldi	r25, 0x01	; 1
DDRB=0xFE;
   2:	8e ef       	ldi	r24, 0xFE	; 254
   4:	87 bb       	out	0x17, r24	; 23
while(1) {PORTB=x;x<<=1;}
   6:	98 bb       	out	0x18, r25	; 24
   8:	99 0f       	add	r25, r25
   a:	fd cf       	rjmp	.-6      	; 0x6 <__zero_reg__+0x5>

Wniesek wynikający z powyższych przemyśleń jest taki , że to nie od kompilatora , tylko użytkownika prawie wszystko zależy

Piotrek

Fredy · Postautor: **Fredy** » 4 lis 2006, o 08:25

Zwróćcie uwagę że pozornie nic nie zawierający program w Bascomie :
$regfile = "2313def.dat"
$crystal = 10000000
End

po skompilowaniu zajmuje już 76 bajtów.
Zatem jest tak że Bascom marnuje trochę pamięci na początku.
Dlatego proponuje porównać dłuższy program.

Przykładowo:

$regfile = "2313def.dat"
$crystal = 10000000
$baud = 9600

Dim X As Word , Y As Word , il As Long

Do
For X = 1 To 50000
For Y = 1 To 50000
il = X * Y
Print "Iloczyn " ; X ; " i " ; Y ; " wynosi:" ; il
Wait 1
Next Y
Next X
Loop
End

zajmuje 726 bajtów.

radzio · Postautor: **radzio** » 4 lis 2006, o 08:28

Natomiast "pusty" program w avr-gcc (bez 'gołych' funkcji itp) zajmuje 160 bajtów. Tak więc nie ma co porównywać rozmaru całości programu łącznie z inicjalizacją zmiennych itp itd, tylko można porównać jak dany kompilator przerobi określony algorytm.

Fredy · Postautor: **Fredy** » 4 lis 2006, o 08:34

Natomiast "pusty" program w avr-gcc (bez 'gołych' funkcji itp) zajmuje 160 bajtów. Tak więc nie ma co porównywać rozmaru całości programu łącznie z inicjalizacją zmiennych itp itd, tylko można porównać jak dany kompilator przerobi określony algorytm.

sorry to nic nie rozumie. Przed chwilą czytałem że bascom jest rozrzutny bo tak prosty program kompiluje w 110 bajtów ( z czego 76 jest przezanczonych na start) a teraz ty mi piszesz że pusty program w C u ciebie zżera 160 bajtów.

pajaczek · Postautor: **pajaczek** » 6 lis 2006, o 17:26

I już na koniec lekko zmodyfikowany listing w C , generuje 12 bajtów kodu wynikowego , którego nie da się "spłodzić" lepiej , nawet w ... assemblerze
Kod: Zaznacz cały
0: 91 e0 ldi r25, 0x01 ; 1 DDRB=0xFE; 2: 8e ef ldi r24, 0xFE ; 254 4: 87 bb out 0x17, r24 ; 23 while(1) {PORTB=x;x<<=1;} 6: 98 bb out 0x18, r25 ; 24 8: 99 0f add r25, r25 a: fd cf rjmp .-6 ; 0x6 <__zero_reg__+0x5>

Ja tam bym dal ROL zamiast ADD, przynajmniej efekt bylby dluzej niz przez 37 cykli

a jak juz koniecznie musi byc tak, to LSL. Jakos tak ladniej wyglada.

sorry to nic nie rozumie. Przed chwilą czytałem że bascom jest rozrzutny bo tak prosty program kompiluje w 110 bajtów ( z czego 76 jest przezanczonych na start) a teraz ty mi piszesz że pusty program w C u ciebie zżera 160 bajtów.

To jeszcze zalezy, co sie do tego "pustego" programu includuje. Same wektory przerwan to juz kilkadziesiat bajtow.

Edit:
Szymel:
Niom... ale ten wyglad (LSL - duzo ladniejszy).

szymel · Postautor: **szymel** » 6 lis 2006, o 19:08

...Ja tam bym dal ROL zamiast ADD, przynajmniej efekt bylby dluzej niz przez 37 cykli

Algorytm programu , to nie mój pomysł

a jak juz koniecznie musi byc tak, to LSL. Jakos tak ladniej wyglada.

Opcode dla LSL Rx i ADD Rx,Rx(gdzie Rx=Rx) jest takie samo i to jaki mnemonik ukaże sie naszym oczom , zależy li tylko od kaprysu disassemblera

Np. 0000 1111 1111 1111 może oznaczać LSL r31 , a może równie dobrze wyglądać jak ADD r31,r31.

Piotrek

Fredy · Postautor: **Fredy** » 6 lis 2006, o 21:21

Bardzo na temat ta dyskusja. Nie ma gdzies kącika dla asemblerowców?

[ Dodano: 06-11-2006, 20:24 ]
A jak juz tak bardzo chcecie pokazac zalety asemblera to napiszcie przykład programiku w asemblerze który zacytowałem wyzejw Bascomie, podajcie jaki uzyskaliscie rozmiarpo skompilowaniu. No chyba ze to jest robota na tydzień

bo ja w Bascomie takie cos pisze w 1minute. I to jest absolutna przewaga nad asemblerem. I jeszcze jedno - znalezienie błedu w bascomie, czy tez zmiana algorytmu lub zmiana procesora to przy pewnej wprawie robota na chwile. W asemblerze to piekło

.

szymel · Postautor: **szymel** » 7 lis 2006, o 09:03

...A jak juz tak bardzo chcecie pokazac zalety asemblera to napiszcie przykład programiku w asemblerze który zacytowałem wyzejw Bascomie, podajcie jaki uzyskaliscie rozmiarpo skompilowaniu.

A po co pisać program , który już na 1-szy rzut oka jest bez sensu

Kto o zdrowych zmysłach , będzie czekał 80 lat na jeden obieg pętli Do Loop

No chyba ze to jest robota na tydzień bo ja w Bascomie takie cos pisze w 1minute. I to jest absolutna przewaga nad asemblerem.

Tu się z Toba zgadzam.

I jeszcze jedno - znalezienie błedu w bascomie, czy tez zmiana algorytmu lub zmiana procesora to przy pewnej wprawie robota na chwile.

W assemblerze również.Dobry kompilator assemblera , posiade nie gorsze "gadżety" ułatwiające życie programiście niz Basic czy C.

W asemblerze to piekło .

Tylko nie zapominaj o tym ,że ktoś inny musiał przejść przez to assemblerowe piekło , byś Ty mógł w 1 minutę , stworzyć programistyczne dzieło

Na zakończenie powiem tylko , że kompilator obojętnie jakiego języka programowania , jest tylko narzędziem i czym więcej tych narzędzi mamy i umiemy się nimi posługiwać , tym życie staje się łatwiejsze

Ale się "rozgadałem".

Piotrek

pajaczek · Postautor: **pajaczek** » 7 lis 2006, o 16:48

A jak juz tak bardzo chcecie pokazac zalety asemblera to napiszcie przykład programiku w asemblerze który zacytowałem wyzejw Bascomie, podajcie jaki uzyskaliscie rozmiarpo skompilowaniu. No chyba ze to jest robota na tydzień

A moze wysylac X, Y i il w hexie ?? taki zajmuje 184 bajty (+16B EEProm), a napisanie zajelo ok godz (wliczajac poszukiwanie algorytnow, bo nie mialem zadnych pod reka - swieze Studio i zadnych archiwow wlasnych), pewnie dalo by sie troche skrocic jeszcze

Choc przyznaje, ze konwersja wyniku, by wysylal wysylal wynik "stringiem" zajmie pewnie blisko drugie tyle.

No chyba ze to jest robota na tydzień bo ja w Bascomie takie cos pisze w 1minute. I to jest absolutna przewaga nad asemblerem.
Tu się z Toba zgadzam.

W C, tez pewnie z minute zajmie, a i optymalizacja bedzie lepsza niz w Bascomie.

szymel · Postautor: **szymel** » 7 lis 2006, o 21:00

... W C, tez pewnie z minute zajmie, a i optymalizacja bedzie lepsza niz w Bascomie.

Muszę Cię zmartwić , bo korzystając ze standardowych bibliotek(a szczególnie z printf) , AVR-GCC generuje kod , który się nie mieści w 90s2313

Nie zmienia to jednak mojego zdania o w/w kompilatorach i w miarę potrzeb , korzystam z każdego z nich.

Piotrek

Fredy · Postautor: **Fredy** » 8 lis 2006, o 10:49

... W C, tez pewnie z minute zajmie, a i optymalizacja bedzie lepsza niz w Bascomie.
Muszę Cię zmartwić , bo korzystając ze standardowych bibliotek(a szczególnie z printf) , AVR-GCC generuje kod , który się nie mieści w 90s2313
Nie zmienia to jednak mojego zdania o w/w kompilatorach i w miarę potrzeb , korzystam z każdego z nich.

Piotrek

sorry ale nie rozumiem, czy zatem ten program w Bascomie mieści się w 726 bajtach i bez problemu zmieści sie w 90s2313 natomiast w C juz nie? Czy dobrze zrozumiałem?

pajaczek · Postautor: **pajaczek** » 8 lis 2006, o 13:16

Szczerze mowiac tez nierozumiem...

Pusty program, + definicja wlasna putchar, putstr; zajmuje mi 126B(napisanie ponizej min

... raptem 7 linijek lacznie, i to ladnie ulozonych). Sam pusty program (przy tej samej optymalizacji) 90B... Nie wierze zeby kompilacja konwersji hex->str byla tak "nieoptymalna"...

A printf moze byc kobylasty, bo i nie byl pisany w perspektywie uzywania na uC z "malymi" zasobami. Pamietajmy ze jest to tylko przeniesione gcc z wiekszych maszyn, nie jak print Bascoma, napisany specjalnie na potrzeby i wymogi AVR/'51.

Kod wynikowy w Bascomie kontra FASTAVR.

Re: Kod wynikowy w Bascomie kontra FASTAVR.

Kto jest online