subtrahieren + addieren

[themaddin]

moin!

Ich möchte gerne mehrere Variablen subtrahieren. Wenn ich folgendes schreibe, kommt eine Fehlermeldung("3 Parameters expected"):

Variable1 = 100 - Variable2 - Variable3

Beim addieren genau das gleiche.
Warum?

MfG
Martin

[chr-mt]

Hi
Bascom kann beim Rechnen nicht mehrere Schritte auf einmal machen.
Du müsstest also alles einzeln machen

variable1=100-variable2
variable1= variable1-variable3

Oder:
Zwischenwert=variable2-variable3
Variable1=100-zwischenwert


Gruß
Christopher

[themaddin]

ja! so habe ich es auch gelöst.
Schade. Das ist nämlich blöd wenn man 6 Variablen subtrahieren möchte....

mfg
martin

[sep]

das ist ja nicht wahr? Das hochgelobte Bascom kann nur eine Operation auf einmal? Dann hab ich einen wirklich guten Grund bei C zu bleiben...
So ein Kinderquatsch!

[pebisoft]

endlich wieder ein framewar.
winavr-c ist eine freeware und hervorragend.
natürlich sollte man sich einmal fastavr-basic anschauen wenn man sich mit den asm-code anfreunden will. fastavr-basic erzeugt asm-sourcecode für den assembler vom avrstudio.
mfg pebisoft

[chr-mt]

Hi,

das ist ja nicht wahr? Das hochgelobte Bascom kann nur eine Operation auf einmal? Dann hab ich einen wirklich guten Grund bei C zu bleiben...
So ein Kinderquatsch!

Das ist wirklich ein Nachteil von Bascom.
Das deswegen komplett abzulehnen, naja, jeder wie er meint.
Bascom bietet nun mal auch eine Menge

Gruß
Christopher

[hrei]

Hallo!

Ja - der Nachteil ist bekannt und gravierend. Anlaß für einen "Framewar" ist es nicht, noch nicht mal für einen Flamewar . Man lernt damit zu leben oder eben nicht.

Die für mich gravierendsten Nachteile habe ich auf meinen Seiten erwähnt, daß ich trotzdem damit arbeite, zeigt, daß die Positiva für mich überwiegen.

Eigenzitat:

An dieser Stelle sollen auch gleich die m.E. wichtigsten Nachtele von Bascom erwähnt werden:

*Bascom kann nur schlecht mit mathematische Ausdrücken umgehen. Als Regel gilt: Eine Berechnung pro Zeile! Wer in Zeiten aufgewachsen ist, als UPN (umgekehrte polnische Notation) bei Taschenrechnern der letzte Schrei war, hat damit wenig Probleme, alle Anderen müssen sich daran gewöhnen. Keine Sorge, das geht.

*Bascom hat, freundlich ausgedrückt, eine sehr umfangreiche, aber ebenso unorganisierte Dokumentation. Man findet Details grundsätzlich nicht da, wo man sie vermuten würde. Es ist unbedingt nötig, sich sämtliche Querverweise anzusehen, um Aufklärung zu bekommen.

*Bascom unterstützt nicht alle Prozessoren der AVR Produktreihe. Das spielt für die hier vorwiegend besprochenen Mega8 und Mega32 zwar keine Rolle, bei dem ebenfalls erwähnten Mega168 wird man aber bereits mit Schwierigkeiten rechnen müssen, obwohl er in der Liste der unterstützten Prozessoren eingeschlossen ist. Es gibt hier Ärger mit der Timerverwaltung. Fairerweise sei aber gesagt, daß es natürlich schwierig bis unmöglich ist, für eine sich ständig erweiternde Produktpalette immer sofort alle Features umzusetzen.

Grüße
Henrik

[sep]

Hm...
Ohne jetzt einen Streit vom Zaun brechen zu wollen, ich finde das wirklich problematisch, denn komplizierte Berechnungen werden so völlig unübersichtlich. Und es kann ja nicht soo schwer sein, einen billigen Parser zu schreiben der einfache komplexe Operationen zerlegt. Ich meine, das bekomme ich ja noch selber hin... Das in Bascom zu integrieren wird wohl kniffliger...

[hrei]

Hallo,

Hm...
Ohne jetzt einen Streit vom Zaun brechen zu wollen, ich finde das wirklich problematisch, denn komplizierte Berechnungen werden so völlig unübersichtlich. Und es kann ja nicht soo schwer sein, einen billigen Parser zu schreiben der einfache komplexe Operationen zerlegt. Ich meine, das bekomme ich ja noch selber hin... Das in Bascom zu integrieren wird wohl kniffliger...

keine Sorge, das gibt keinen Streit . Diese echte Macke wird schon seit Erscheinen von Bascom bemängelt. Mir ist auch kein Hochsprachencompiler bekannt, der in der Beziehung noch so vorsintflutlich ist.

Warum steige ich denn dann nicht um? Na, in Basic habe ich nicht wirklich eine Alternative- Trotzdem habe ich vor Umstieg auf Bascom meine zur Portierung vorgesehenenen Programme auf das vorkommen umfangreicher Rechenoperationen geprüft und festgestellt, daß das so viele überhaupt nicht sind.

Die werden nun in Funktionen ausgelagert, die notwendigen Variablen als local deklariert (das frisst kaum Brot) und die Übersichtlichkeit bleibt gewahrt. Damit ich und andere den Überblick in der Funktion nicht verlieren, kommt die ursprüngliche Formel als Kommentar an den Anfang.

Gut ist etwas anderes, man lernt aber damit zu leben um die Vorteile von Bascom nutzen zu können.

Kritkwürdig ist allerdings, daß in letzter Zeit Änderungen, Updates, Implementation neuer Prozessortypen nur noch schleppend und halbherzig geschieht. Insbesondere das mangelnde Feedback seitens MCS nervt ein wenig. Ich wäre ja durchaus bereit für solche Updates einen angemessenen Preis zu zahlen, wenn sie denn fehlerfrei wären.

Auch für aussagekräftige Fehlermeldungen (seit der aktuellen Version gibt es fast nur noch "file not found"), bei denen man durch anklicken auch wirklich in die entsprechende Zeile kommt, würde es mal Zeit.

In diesem Sinne und der Hoffnung hinreichend klargemacht zu haben, daß auch Bascom Fans keineswegs blind sind...

Viele Grüße
Henrik

[oe9vfj]

Der Umstand, dass BASCOM-AVR nur eine math. Operation pro Basic-Statement erlaubt, ist sicher ein echter Schönheitsfehler welcher auch vom größten BASCOM-Fan störend empfunden wird. Wie aber schon in diesem Thread mehrfach erwähnt, zählt nicht nur ein Feature, sondern was eine Software insgesamt zu bieten hat und da ist BASCOM-AVR für mich eindeutig in der Führungsposition unter den Basic-Compilern für AVR.

Gerade bei der Mikrocontroller-Programmierung zählt nicht (nur) die Optik des Anwenderprogrammes, sondern der Maschinencode, welcher vom Compiler generiert wird und dann auf der Hardware läuft.

Dass ein Compiler (fastAVR), welcher mehrere math. Operationen in einem Befehl verarbeitet (mit Ablage von Zwischenergebnissen auf dem Stack) nicht unbedingt den besseren Code erzeugt (bzw. erzeugen kann) möchte ich an einem einfachen Beispiel zeigen:

Folgendes Programm auf einem AVR (Mega):

' Multiplikation von 2 Byte Variablen und Addition einer Konstanten Zahl
' B1 = B1 * B2 + 5

Dim B1 as Byte, B2 as Byte

B1 = B1 * B2 + 5

fastAVR erzeugt hier:

;-Line--0014----b1 = b1 * b2 + 5--
lds zl,b1
push zl
lds zl,b2
pop r24
mul zl,r24
movw zl,r0
push zl
ldi zl,Low(5)
pop r24
add zl,r24
sts b1,zl

(28 Byte Codegröße mit 20 Takte Ausführungszeit)

Es wird eine Variable (b1) zuerst in das zl-Register geladen und dann mit push und pop über den Stack in das register r24 verschoben, anstatt diese gleich in das register r24 zu laden. Um dann zum Ergebnis der Multiplikation (in r0) die Zahl 5 zu addieren wird dieses mit einem Word-Verschiebe Befehl in das zl-Register verschoben, dort kann es aber nicht bleiben, da die Konstante 5 auch in dieses Register geladen wird.
Daher das gleiche Spiel wie zu Beginn mit dem Verschieben in das r24-Register mit den Umweg über den Stack bevor die Addition vorgenommen wird. Das Ergebnis hätte aber ohnehin in r0 verbleiben können, anstatt es höchst ineffektiv zweimal weiter zu verschieben.
Nebenbei bemerkt: Auch die Verwendung von Pointer-Register (hier Z) zur Zwischenspeicherung von Variablen lässt meines Erachtens nicht auf ein durchdachtes durchgängiges Konzept schließen.

Ein effektiver Code könnte z.B. so aussehen:

lds r24, b1
lds r24, b2
mul r24, r25
ldi r24, 5
add r24, r0
sts b1, r24

(18 Byte Codegröße mit 10 Takte Ausführungszeit)

fastAVR hat einen um 56% größeren Code mit sogar doppelter
Ausführungszeit erzeugt.


Da bei Bascom durch die Einschränkung auf eine math. Operation pro Basic-Befehl die Zwischenergebnisse naturgemäß in das SRAM gespeichert werden, ist auch hier nicht der kürzest mögliche Code gegenüber einer händischen ASM-Programmierung möglich:

BASCOM-AVR erzeugt für:

B1 = B1 * B2 : B1 = B1 + 5

' B1 = B1 * B2
Lds R16,$0100 ' B1 in r16
Lds R20,$0101 ' B2 in R20
mul R16,R20
Ldi R26,$00 ' Addresse von B1
Ldi R27,$01
St X,R0
' B1 = B1 + 5
Ldi R26,$00 ' Adresse von B1
Ldi R27,$01
Ld r24,X
Subi r24,-5
St X,r24

(26 Byte Codegröße mit 17 Takte Ausführungszeit)

Damit ist aber der von BASCOM-AVR erzeugte Code kürzer und schneller als der fastAVR Code.