bascom kann sich sehen lassen.

[pebisoft]

hallo, ich habe mal ein vergleich angestellt zwischen winavr und bascom.
der programcode (bin-datei die in den AVR geladen wird) von winavr ist
teilweise bei gleichen leistungen ca 6-7 % grösser als bei bascom,
dies trifft komischer weise auf alle programme zu.
die geschwindigkeit von winavr ist um ca 30% schneller, aber nur bei
schleifen oder zu den unterprogrammen. dies kommt daher, weil bei Bascom
immer alle register gesichert werden. dies kann man durch einen befehl
abstellen. dadurch wird winavr nur noch ca 8-15% schneller.
die bascom-programme kann man noch beschleunigen, wenn man die befehle
aus der deviceAtmega...datei nimmt, ganze ports für adc, timer, interrupt
usw. direkt beschreibt. es sieht also mit Bascom garnicht so schlimm
gegenüber winavr aus. da man in winavr auch bestimmte zeitkritische routinen
in asm reinbringt (zb. bei fbas-video mit dem AVR darstellen), steht es um uns
bascomer gar nicht so schlecht. es gibt immer wieder horrormeldungen
das Bascom langsam ist und ein speichenrfresser, mitnichten dem ist nicht so.
einziger nachteil ist, das man in Bascom nicht verfolgen kann warum
das bit 4567 beim 345zigstenmal setzen nicht 3,4 us sondern nur 3,388 us braucht.
wer solche sachen verfolgen möchte ist mit winavr besser dran.
viel spass mit bascom. nebenbei progge ich auch mit winavr.
den küchenbrettroboter progge ich in bascom.
mfg pebisoft

[Marco78]

Welcher Befehl beschleunigt denn den Aufruf von Unterprogrammen und Schleifen? (Was ja ein wesentlicher Teil von Programmen ist).

Und eine wohlmöglich blöde Frage habe ich noch
Befehle auf deviceAtmega...datei??? Kannst du da etwas näher drauf eingehen?

Thx!

[pebisoft]

bei Bascom wird der unterprogrammaufruf durch sichern sämtlicher register aufgehalten. durch den befehl "nosave" kann man dieses beschleunigen.
dies sind die registerbefehle , die man direkt setzen kann, diese bascomwörter erscheinen in der hilfe und sind reserviert bei "avr internal registers":
stehen in der jeweiligen "dat" für den avr, zb aus der m16def.dat :

;***** I/O Register Definitions
.equ SREG =$3f
.equ SPH =$3e
.equ SPL =$3d
.equ OCR0 =$3c
.equ GICR =$3b ; New name for GIMSK
.equ GIMSK =$3b
.equ GIFR =$3a
.equ TIMSK =$39
.equ TIFR =$38
.equ SPMCR =$37
.equ I2CR =$36
.equ TWCR =$36
.equ MCUCR =$35
.equ MCUSR =$34
.equ MCUCSR =$34 ; New name for MCUSR
.equ TCCR0 =$33
.equ TCNT0 =$32
.equ OSCCAL =$31
.equ SFIOR =$30
.equ TCCR1A =$2f
.equ TCCR1B =$2e
.equ TCNT1H =$2d
.equ TCNT1L =$2c
.equ OCR1AH =$2b
.equ OCR1AL =$2a
.equ OCR1BH =$29
.equ OCR1BL =$28
.equ ICR1H =$27
.equ ICR1L =$26
.equ TCCR2 =$25
.equ TCNT2 =$24
.equ OCR2 =$23
.equ ASSR =$22
.equ WDTCR =$21
.equ UBRRHI =$20
.equ UBRRH =$20 ; New name for UBRRHI
.equ EEARH =$1f
.equ EEARL =$1e
.equ EEDR =$1d
.equ EECR =$1c
.equ PORTA =$1b
.equ DDRA =$1a
.equ PINA =$19
.equ PORTB =$18
.equ DDRB =$17
.equ PINB =$16
.equ PORTC =$15
.equ DDRC =$14
.equ PINC =$13
.equ PORTD =$12
.equ DDRD =$11
.equ PIND =$10
.equ SPDR =$0f
.equ SPSR =$0e
.equ SPCR =$0d
.equ UDR =$0c
.equ UCSRA =$0b
.equ USR =$0b ; For compatibility with S8535
.equ UCSRB =$0a
.equ UCR =$0a ; For compatibility with S8535
.equ UCSRC =$20 ; Note! UCSRC equals UBRRH
.equ UBRR =$09
.equ UBRRL =$09 ; New name for UBRR
.equ ACSR =$08
.equ ADMUX =$07
.equ ADCSRA =$06
.equ ADCSR =$06
.equ ADCH =$05
.equ ADCL =$04
.equ TWDR =$03
.equ TWAR =$02
.equ TWSR =$01
.equ TWBR =$00
.equ I2DR =$03
.equ I2AR =$02
.equ I2SR =$01
.equ I2BR =$00

mfg pebisoft

[Werner_Just]

Hallo Pebisoft,

wenn man "nosave" verwendet muß man sich von Hand darum kümmern die im Unterprogramm verwendeten Register zu sichern.

Rauszubekommen welche Register zu sichern sind ist nicht ganz einfach. Entweder kann man dies im Simulator mit Snapshot machen, oder man disassembliert das erzeugte bin-File und analysiert dieses.

Schöner wäre es, wenn Bascom das selbstständig machen würde. Quasi als 2pass-Compiler. 1. Compilerlauf wie gehabt, 2. Compilerlauf alle unnötigen push/pop entfernen.

Vieleicht liesse sich sowas auch als Plugin für Bascom realisieren, aber dafür kenn ich mich zuwenig aus.

Ciao,
Werner

[Kjion]

der programcode (bin-datei die in den AVR geladen wird) von winavr ist teilweise bei gleichen leistungen ca 6-7 % grösser als bei bascom,dies trifft komischer weise auf alle programme zu.
die geschwindigkeit von winavr ist um ca 30% schneller, ...

Mich würde mal interessieren mit welchen Programmen du das gemessen hast ?? Kannst du dir hier mal posten ??

MfG Kjion

[Frank]

Ja, je nach Benchmark sieht mal der eine oder andere etwas besser aus. Das ist fast wie mit den Statistiken der Politik. Paßt einem das Ergebniss nicht nimmt man einen anderen Benchmark!

Da sowohl WinAvr und Bascom praktisch kleine Assemblerroutinen einfügen sind die von der Geschwindigkeit und Codeumfang sicher nicht sehr unterschiedlich. WinAvr verbraucht vielleicht manchmal ein paar Bytes mehr weil einige Libary Funktionen in C geschrieben wurden, bei Bascom ist glaub doch das meiste in Assembler geschrieben.

bei Bascom wird der unterprogrammaufruf durch sichern sämtlicher register aufgehalten. durch den befehl "nosave" kann man dieses beschleunigen

Ich kann hier nur warnen! Das NOSAVE sollte wirklich nur der benutzen der genau weiss welche Register benutzt werden. Eigentlich ist das in der Regel nur der Fall wenn die Unterroutine in Assembler eingefügt wird.
Ansonsten kann die Verwendung von NOSAVE Fehler hervorrufen die kaum aufzuspüren sind und nicht selten nur in ganz bestimmten Situationen auftreten. Ich hab da auch meine leidigen Erfahrungen mit NOSAVE, plötzlich hatte ich bei einem Board Tastenbetätigungen ohne das Taste gedrückt wird. Das ganze war noch dazu so selten das es kaum rekonstruierbar war, die Ursache für sowas zu finden ist richtig Arbeit!

Selbst wenn man nur eine einfache Basic-Anweisung im Interrupt hat, sollte man nicht NOSAVE verwenden ohne bedacht nehmen.

In der Regel ist der Zeitgewinn sowieso bei den meisten Anwendungen zu vernachlässigen da es sich hier nur um Mikrosekunden handelt (Millionstel Sekunden).

[Werner_Just]

Hallo Frank,

In der Regel ist der Zeitgewinn sowieso bei den meisten Anwendungen zu vernachlässigen da es sich hier nur um Mikrosekunden handelt (Millionstel Sekunden).

was die Zeit angeht kann ich Dir nur zustimmen.

Wenn man aber gezwungen ist geschachtelte Interruptaufrufe zulassen zu müssen, dann wird Nosave interessant, weil man viel Speicherplatz auf dem Stack sparen kann.
Einfacher ist es aber imo auch hier auf NOSAVE zu verzichten und das ganze von Hand mit dem Disassembler aus dem Studio4 zu optimieren.

Innerhalb von Bascom hat man praktisch keine Möglichkeit rauszufinden welche Register verwendet werden. Das geht nur via Snapshot im Simulator, aber da hat man spätestens dann ein Problem, wenn innerhalb der Routine Verzweigungen vorhanden sind. Man muß dann sicherstellen, das alle Programmpfade durchlaufen werden, sonst hat man ruckzuck ein Register übersehen.

Ciao,
Werner

[PicNick]

Die effektive Hex-Größe hängt maßgeblich davon ab, wie die Libraries strukturiert sind, da der Linker ja nicht einzelne Funktionen rauspicken kann.
Ich konnte die Bascom Hex noch nicht wirklich analysieren, ich bin mir aber einigermaßen sicher, daß sich die Code Ergebnisse der einzelnen Statements, Schleifenkonstukte und Adressierungen kaum wesentlich unterscheiden werden, da ja der ATMEL ja für alle Kompiler die gleichen Sachzwänge aufstellt.

[PicNick]

Innerhalb von Bascom hat man praktisch keine Möglichkeit rauszufinden welche Register verwendet werden.

Beim WinAvr ist recht gut dokumentiert, welche Register er wofür verwendet, und wer für welche Sicherung zuständig ist. Leider gibt's das beim Bascom so genau nicht.
mfg