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
Druckbare Version
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
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
ja! so habe ich es auch gelöst.
Schade. Das ist nämlich blöd wenn man 6 Variablen subtrahieren möchte....
mfg
martin
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!
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
Hi,
Das ist wirklich ein Nachteil von Bascom.Zitat:
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 deswegen komplett abzulehnen, naja, jeder wie er meint.
Bascom bietet nun mal auch eine Menge ;)
Gruß
Christopher
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:
GrüßeZitat:
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.
Henrik
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...
Hallo,
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.Zitat:
Zitat von sep
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
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.
Was nutzt effizienter Code, wenn er nicht korrekt ist?
Ok, nur ein Tippfehler *haarespalt* ;-)Zitat:
Zitat von oe9vfj
Ich hab mal interessehalber geschaut, was avr-gcc da macht:
Da bleibt nix zu wünschen übrig :-)Zitat:
Zitat von avr-gcc
Das clr r1 kommt daher, das in r1 immer die Konstante 0 gehalten wird um viele Sachen effizienter zu erledigen.
BTW: Gibt es kein BASIC-Frontend für GCC? Oder in Planung?
Was GCC an Optimierungen mitbringt ist ja der Hammer. Was fehlt wäre nur ne neue Sprache dranzustöpseln wie C,C++,Ada,etc
Middle- und Backend müssten wohl kaum angepasst werden.
OK, das ist ein Tippfehler. Das ändert aber nichts an der grundsätzlichen Aussage, dass BASCOM-AVR trotz der Zerlegung in zwei Basic-Befehle einen kompakteren und schnelleren Code erzeugt als fastAVR, welcher diesen math. Audruck in einem verarbeitet.
Interessant ist auch Dein Vergleich mit avr-gcc, ich werde aber trotzdem bei BASCOM-AVR bleiben.
Wie ein Compiler/Interpreter intern mit Ausdrücken umgeht ist mehr oder weniger unabhängig davon, wie er in der Quelle hingeschrieben werden muss. Jedenfalls sollte das so sein, wenn ansatzweise optimiert wird.
Was BASCOM da anstellt ist ja heftig. Warum macht das so viel unnötiges Zeug? Kein Winder, wenn da fix das Flash voll ist.
es gibt verschiedene programmierer.
bei den einen kommt es nicht auf die optimierte umsetzung des codes an
sondern das der sensor einfach und korrekt angesprochen wird.
denen interessiert zwar der code, machen hier und da vorschläge
aber können den source-code nicht optimieren weil diese gruppe
in bascom programmiert.
bei der nächsten gruppe handelt es sich um leute, die wissen wollen
was im avr vor geht und möchten schnellen ausführungscode.
die gehören zur gruppe der winavr-c-progger.
zwar lässt sich in winavr-c der code durch schalter optimieren,
aber es fallen dann manchmal auch routinen zum opfer die
gebraucht werden, aber durch den optimierungschalter für unwichtig
eingestuft werden und weg sind sie. hier muss man dann immer
den mittelweg suchen. aber die könner liegen mit winavr-c
schon richtig, weil ohne das kennen der interna vom avr
auch winavr-c nicht das richtige ist.
die dritte gruppe möchte die optimalsten programme und die
gib es nur, wenn nach dem compilieren ein asm-sourcecode vorliegt
den man dann verbessern kann und wieder neu compilieren kann in der
gleichen gui-oberfläche ohne gross aus dem programm auszusteigen.
dafür nimmt man fastavr-basic. hier ist man hautnah mit dem avr auf du und du.
und es gibt keinen faulen tricks mehr.
alle oben erwähnten programme machen nicht das optimalste ergebnis
daraus. das eine programm hat hier mängel und das andere programm
hat dort mängel. der user darf aber vom asm-sourcecode nicht ausgesperrt
werden. und bei fastavr-basic wird er nicht ausgesperrt.
ein waschechter proggi zeigt auch interesse am ändern und
gibt sich nicht mit dem vorgegebenen zufrieden, nach dem motto:
vogel friss oder stirb.
hier ein einfaches beispiel wie es in fastavr-basic geht.
eine gleichung "b1=b1*b2+b3" in verschiedenen varianten.
1. original b1=b1*b2+b3 :
;-Line--0012----b1=b1*b2+b3--
lds zl,b1
push zl
lds zl,b2
pop r24
mul zl,r24
movw zl,r0
push zl
lds zl,b3
pop r24
add zl,r24
sts b1,zl
2. original b1=b1*b2
b1=b1+b3 :
;-Line--0009----b1=b1*b2--
lds r24,b1
lds zl,b2
mul zl,r24
movw zl,r0
sts b1,zl
;-Line--0010----b1=b1+b3--
lds r24,b1
lds zl,b3
add zl,r24
sts b1,zl
3. eine verbesserte version. eine von den obigen (die 2.) wurde sich
bei einem glas rotwein kurz vorgenommen und verbessert
und dann wieder in der gleichen gui von fastavr-basic neu compiliert :
lds r24,b1
lds zl,b2
mul zl,r24
movw r24,r0
lds zl,b3
add zl,r24
sts b1,zl
mfg pst
Öhm... hab ich das richtig verstanden?
Du nimmst was dein Basic-Compiler ausspuckt, schnitzt dran rum und futterst das Assembler damit?
Dann kann ich auch gleich nen Assembler hernehmen für zeitkritische Module; dann ist mein Code wenigstens gescheit kommentiert.
Aber immer hinter nem Compiler herzuwischen ist doch nervig, zeitraubend und fehleranfällig. Wenn der erzeugte Code mies ist, dann zieht sich das ja durchs ganze Projekt und ist nicht auf einzelne Stellen berschränkt. Und wenn ich in der Quelle was kleines ändere, fängt alles wieder von vorne an *graus*.
Und gcc wird niemals nicht was wegwerfen, das noch gebraucht wird. Er wird eher meckern, wenn was definiert wird, das unnötig ist. Wird hingegen was nicht gebraucht, landet's eben in der Tonne -- wo's auch hingehört.
ich habe das fastavr-basic gekauft um bei asm in der nähe zu sein..
das fastavr-basic kann den assembler auch sofort damit füttern ohne das ich etwas ändere. die bascomprogger haben den nachteil das sie es nicht machen können obwohl sie es gerne täten und die lib dazu, mag garnicht dran denken.
ich finde es als hobby ganz toll, so etwas zu ändern/schnitzen und zu tüfteln und zu schauen, wie es in asm aussieht. sonst ist es kein hobby mehr. beim hobby muss man zeit... haben, wenn es einen zu zeitraubend vorkommt, soll man etwas anders machen.
wer perfekt ist, der muss in das andere avr-forum gehen, dort gibt es fast nur ing. und techniker die für firmen entwicklen und geldverdienen müssen. die lachen nur über dieses forum und sagen: was ihr macht ist kinderkram.
aber so ist das halt. der eine macht das so und der andere so.
auch wird von den ing und den technikern sogar der winavr-c nicht ernst genommen, obwohl die leistung von dem schon eigenermassen gut ist für unseren hobbybereich. die guten kosten etwa ab 500 euro in der mittelversion. ich will damit auch nur sagen, das man uns in diesem forum nicht so ernst nehmen soll in der technik und alles ganz locker sehen soll. wir hier alle sind nur kleine künstler und keine fachleute, der eine beugt sich ein bisschen mehr aus dem fenster und der andere ein bisschen weniger, aber in wirklichkeit befinden wir uns hier im unteren wissensbereich worüber die anderen schmunzeln.
ich glaube wer ein fundiertes wissen hat mit dem avr und progg-sprachen, der wird sein wissen zu geld machen.
mfg psf
Hallo Pebisoft,
wie immer siehst du die Dinge sehr subjektiv. ;)
Ich zB. will gar nicht in Assembler rumbasteln.Zitat:
die bascomprogger haben den nachteil das sie es nicht machen können obwohl sie es gerne täten
Dann sollen sie mal lachen. Wobei ich das nicht glaube.Zitat:
dort gibt es fast nur ing. und techniker die für firmen entwicklen und geldverdienen müssen. die lachen nur über dieses forum und sagen: was ihr macht ist kinderkram.
Hier gibt es richtig fähige Leute, Ingenieure und Techniker, die sehr wohl wissen, was sie tun.
(Ich denke da zB. an Jan, den ich seit Jahren auch persönlich kenne)
Es gibt genug Ingenieure, die auch Bascom sehr ernst nehmen.Zitat:
auch wird von den ing und den technikern sogar der winavr-c nicht ernst genommen, obwohl die leistung von dem schon eigenermassen gut ist für unseren hobbybereich.
Stimmt, deshalb beschäftige ich mich beruflich ja auch mit AVRs und ausschließlich mit Bascom, da es für meine Anforderungen mehr als ausreichend ist. Und das in einem High-End Bereich...Zitat:
ich glaube wer ein fundiertes wissen hat mit dem avr und progg-sprachen, der wird sein wissen zu geld machen.
Ich bin leider kein Programmierguru, eher das Gegenteil ;). Eben deshalb ist Bascom für mich die richtige Wahl. Einfach und Effizient.
Ich habe schon mal geschrieben, daß es in vielen Fällen eben NICHT auf extreme Ausführungsgeschwindigkeit ankommt, sondern auf kurze Entwicklungszeiten, gute User-Interfaces, das kurzfristige einbinden von Kundenwünschen usw.
Und nicht jeder hat Zeit oder Lust, am jedem Bit rumzuoptimieren.
Das mag in anderen Bereichen, in denen es um höchste Effizienz geht, unerläßlich sein, aber so ist das eben nicht überall.
Was bringt mir es, wenn ich Daten in 10 µS bearbeite, wenn ich die nur zB. alle 10mS senden muß und der Controller die restliche Zeit nur rumgammelt ? ;)
Was für dich gilt, gilt eben nicht unbedingt für andere Leute.
Wenn du dich gerne mit Optimierungen, Verbesserungen beschäftigst,
dann ist das schön für dich und für manch anderen, der davon lernen kann.
Aber du kannst nicht einfach Leuten die Professionalität absprechen, nur weil sie es nicht so machen, wie du.
Gruß
Christopher
Hallo pebisoft,
> es gibt verschiedene programmierer.
Warum nur wuste ich schon nach dem Lesen der ersten 3 Sätze, das Du es bist? ;-)
Ist jetzt aber nicht böse gemeint. Am Artikel ist nichts auszusetzen.
Aber zu Deinem letzen Artikel muß ich sagen, das jeder eine Change bekommen sollte mit diesem Hobby anzufangen. Überall fangen wir ersteinmal ganz doof an. Ob es beim Krabbeln, bei der Fahrschule oder in der Robotik ist. Daran ist nicht schlechtes. Ich bezweifle, das man über uns lacht. Im Gegenteil: aus den jungen (14Jährigen) Tüftlern von heute wächst die Konkurenz von morgen heran.
Gruß Dirk
ich meine nicht die kids sondern die erwachsenen, die hier versuchen eine promiseite zu kreieren und alles toternst nehmen über die schmunzelt man im anderen forum.
wenns um zeiten in us geht muss ich sehr wohl auf asm-verbesserungen achten. gerade in meinem fall, wo ich mit einem avr wieder dieses fbas-fernsehbild dargestellt habe und das nur in fastavr-basic. wenn ich hier und da etwas ändere , wird das bild schon sehr stabiler, ist kaum zu glauben. diese darstellung gab es zur zeit nur mit winavr-c.
mfg psf
Hi,
ich weiß nicht, welche "Erwachsene" hier eine Promiseite (wobei ich nicht genau weiß, was du damit meinst) kreieren wollen, wen meinst du denn ??
(oder meintest du Profi-Seite ??)
Ich habe bis jetzt nicht den Eindruck, daß hier alles todernst genommen wird. Eher im Gegenteil. Wenn hier alles todernst genommen würde, wäre ich schon lange nicht mehr hier ;)
Wenn anderswo über das Forum geschmunzelt wird, dann ist das für mich absolut OK.
Ich bin nicht umsonst auf dieses Forum gekommen.
In Foren, wo man auf andere herabsieht, fühle ich mich nämlich nicht wohl.
Bei einem Programm wie FBAS Ausgabe direkt mit dem AVR ist natürlich klar, daß man ohne Assembler kaum Erfolg haben wird.
Für mich ist es aber nicht gerade erstrebenswert, in einem Basic Compiler Programme zu schreiben und die im Nachhinein wieder im Assembler zu zerpflücken und auszubessern.
Das es die Möglichkeit gibt, ist natürlich nicht schlecht.
Gruß
Christopher