Zitierennoch ein kleiner off-topic-Hinweis zu GOTO:
Mit GOTO 0 kann man in Bacom den µC reseten, ist manchmal auch nicht verkehrt.
Ich hab' da noch ein paar Beispiele hinzugefügt. Vielleicht will wer gucken.
Abgefeimte Assembler-Fuzzies bekommen da natürlich Tränen in die Augen, aber wat is, det is.
https://www.roboternetz.de/wissen/in...de#BITVARIABLE
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
noch ein kleiner off-topic-Hinweis zu GOTO:
Mit GOTO 0 kann man in Bacom den µC reseten, ist manchmal auch nicht verkehrt.
hmm ich muss das nu noch mal ausgraben-.....weil ichs eben erst gesehen hab..
Vergiss einfach die Antwort von dremler. Er liefert immer wieder solche Antworte. Mal abgesehen davon, dass es beim Goto-Befehl in Bascom noch keine Probleme gab und man diesen Befehl fast nie verwendet...
@jon:
woher nimmst du deine weisheiten?? das ich städig sowas schreiben würde?? außerdem gibt es auch leute die dieser befehl sehr wohl und auch oft verwenden.....also bist du es wohl der hier sachen schreibt die man vergessen sollte.....
Welche Möglichkeiten gibt es denn überhaupt den Erfolg irgendwelcher Optimierungsversuche festzustellen?Den Bascom-Code zu optimieren ist ein Thema, zu dem es bisher noch meiner Meinung nach viel zu wenige Infos gibt. Ich bin gespannt, was da noch kommt!
Beim Compilieren zeigt der Compiler an, wieviel Speicher das Programm belegt. Das ist zwar ein Anhaltspunkt, da aber nur angegeben wird wieviel Prozent des Speichers das gesamte Programm belegt, ist es für kleinere Optimierungen in einem grüsseren Programm nicht besonders genau.
Mit AVR Studio kann man den von Bascom compilierten Code durch den Disassembler jagen. Wenn man Assembler versteht, kann man dann natürlich sehen, was Bascom da zusammengebastelt hat.
Wenn man - wie ich - kein Assembler versteht, kann man höchstens die Zeilen zählen. Wenn man das nach jeder kleineren Änderung macht um den Erfolg festzustellen, ist das aber auch recht mühsam.
Wiwviel Speicvher das gesamte Programm belegt oder wieviel Zeilen Assemblercode Bascom daraus macht ist ja auch oft gar nicht so wichtig.
Intreressanter ist es oft bei einzelnen Routinen die häufig, oder sogar per Interrupt aufgerufen werden.
Welche Möglichkeiten gibt es denn da, festzustellen was Bascom daraus macht.
Oder anders gefragt, wie kann ich feststellen wieviel Takte der Controller z.B. für meine Interrupt-Routine benötigt, und ob der Optimierungsversuch überhaupt ewas gebracht hat?
Hallo,
Assemblerzeilen zählen bringt nur wenig....kann man höchstens die Zeilen zählen
Ausser wenn es nur um den Flash-Verbrauch geht.
Wenn es um die Geschwindigkeit geht,
ist oft ist der längere Code sogar der schnellere.
Stichwort: Ausrollen von Schleifen
Gruß Jan
@JanB jupp, das Ausrollen kleinerer schleifen kann sinnvoll sein, ebenso zu nennen wären vielleicht noch:
- überprüfen ob dinge doppelt oder unnütz berechnet werden
- überprüfen, ob funktionen oder werte nicht als tabelle im speicher vorab abgelegt werden können
- möglichst subs oder funktionen vermeiden, sondern gosub verwenden
Eine Möglichkeit, die Erfolge von Optimierungen zu überprüfen ist, am Anfang des betreffenden Codes einen Counter zu starten und diesem an Ende des Codes auszulesen.
@dremler: sicherlich funktioniert der goto-Befehl absolut zuverlässig, aber ich habe bisher noch keinen Programmcode mit vielen gotos gesehen, den man nicht viel eleganter und besser lesbar ohne 95% der gotos hinbekommen kann.
Ein gutes Listing/Programm kommt deshalb ohne viele gotos aus. Ich hab mal nachgeschaut - in meinem Programm für Marvin gibt es maximal 1 oder 2 gotos, und das bei mehr als 10.000 Programmzeilen. Mit vielen Sprüngen wäre das Lesen und Verstehen so eines Codes wohl auch kaum noch möglich.
Gruß MeckPommER
Mein Hexapod im Detail auf www.vreal.de
Ich würde ja gern die Welt verändern..., doch Gott gibt mir den Quellcode nicht!
In ASM kommt man ja ums Springen nicht herum, wenn auch die meisten Sprünge bedingte Sprünge sind, deren Basic-"Gehaltsequivalent" ich eher in einem "IF" als einem "Goto" sehe.
Klar, jeder kann natürlich programmieren, wie ihm/ihr beliebt. Man kann seine Suppe auch mit einer Gabel löffeln, sollte aber nicht versuchen, andere von den Vorzügen zu überzeugen
Mein Hexapod im Detail auf www.vreal.de
Das ist mir eigentlich klar, daher habe ich ja gefragt, wie man bei einzelnen Routinen feststellen kann wie schnell (in wieviel Takten) diese ausgeführt werden.Assemblerzeilen zählen bringt nur wenig.
Ausser wenn es nur um den Flash-Verbrauch geht.
Die Gefahr ist bei einem grösseren Programm sicherlich gegeben.- überprüfen ob dinge doppelt oder unnütz berechnet werden
Dass man das selber prüfen muss und die Entscheidung welche Programmteile unnütz sind nicht irgendeinem Tool oder dem Compiler überlässt, finde ich aber eigentlich ganz OK
Das wird vermutlich erst ab einer gewissen "Komplexität" der Funktionen Vorteile bringen und wenn ich da richtig liege, ist es halt hilfreich, wenn man den Erfolg auch prüfen kann.- überprüfen, ob funktionen oder werte nicht als tabelle im speicher vorab abgelegt werden können
OK, das ist mir neu. Kommt mir aber entgegen, da ich eigentlich immer zu faul war Subs und Funktionen zu nutzen und mir das erst in diversen Codeschnipseln und Beispielprogrammen abgeguckt habe.- möglichst subs oder funktionen vermeiden, sondern gosub verwenden
Ich habe es mal über nen Zähler in einer Interrupt-Routine versucht, dabei aber irgendwie so rumgemurkst, dass nichts sinnvolles dabei rauskam.Eine Möglichkeit, die Erfolge von Optimierungen zu überprüfen ist, am Anfang des betreffenden Codes einen Counter zu starten und diesem an Ende des Codes auszulesen.
Einen Counter zu verwenden ist ein guter Plan
Reicht es, wenn man das im Simulator macht oder pfuscht da das seltsame Verhalten von Windows rein?
Um die Takte über einen Counter zu zählen sollte ja eigentlich der Simulator reichen und das Multitasking von Windows keine Rolle spielen.
mein Dank an PicNick - sehr schön die Bsp.
mir kommen die Tränen bei der PortPin abfrage.
tschüß sc
Its not a bug its a feature
Berechtigungen
Lesezeichen