Hallo Es geht darum im Avr Studio in Assembler zu programieren unter Einbindung von Variabeln und Rechen Funktionen die sehr einfach zu handhaben sind. Das ganze ist mit Hapsim einfach zu testen (die xml um Hapsim zu konfigurieren ist dabei). Es ist keinesfalls vollständig aber sehr ausbaufähig. Es gibt auch eine Hilfe Datei dazu. Um zu verstehen, was dahinter steckt, muss man sich wohl etwas Zeit nehmen. Die paar Befehle die ich zum Testen reingeschrieben habe, sollen einen kurzen Eindruck vermitteln und machen nur Sinn, wenn sie mit F10 im Simulator durchgetackert werden. Ich wünsche Euch viel Spaß beim Testen und analysieren und hoffe, dass sich einige finden, die es mit mir weiter entwickeln wollen. viel Spass
Hallo Günter, also ich programmier ja wirklich sehr viel in Asm, hab aber nach dem Blick in den Code nicht die leiseste Ahnung wie ich das irgendwie nutzbringend verwenden sollte. Schon gar nicht ist das kinderleicht, wenn man "um zu verstehen...sich wohl etwas Zeit nehmen" muss. Ich finde sowieso, daß die ungezügelte Ergänzung und Ersatz von Asm-Code mit irgendwelchen kunstvollen Makrokonstruktionen ein Asm-Programm nicht gerade einfacher lesbar/verständlich macht. Dann nimmt man lieber gleich eine Hochsprache. Grüße vom Rich
Hallo Rich
Ich programieree seit ca 27 Jahren assembler (angefangen mit der 6502).
Das mit der Hochsprache ist genau der Punkt. Wenn ich Assembler zum
Einsatz bringe, will ich den Prozessor ausreitzen in Sachen
Geschwindigkeit und mit Interrupts. Wenn ich im assembler trotzdem
elegant Variabeln verwenden kann, ist das eine Bereicherung. Wenn du dir
die Befehle anschaust, entsprechen sie den asm Befehlen. Nur mit dem
Unterschied, dass sie nicht nur ein Byte beeinflussen, sondern eben die
Bytes, die in der Variable / den Variabeln beeinflusst werden sollen.
Vergleichbar mit denen eines 16 oder 32 Bit Prozessors.
kleines Beispiel: Du willst eine 32 Bit Zahl im Ram mit 100 addieren.
.dseg
Lable Byte 4
.cseg
....
ldi r16,100
lds r17,Labele
add r17,r16
sts r17,Lable
.....
sieht bei mir so aus:
_long Lable
....
_addi Lable,100
Wenn Du dir im Reassembler anschaust, was aus den beiden Zeilen wurde,
wirst Du genau das finden, was Du sonst mit vielen Befehlen schreibst.
Ich denke, die Lesbarkeit hat damit nicht eingebüßt. davor und danach
kann ich wie gewohnt in assembler weiter programieren. die Befehle
_input und _print haben primär nichts damit zu tun. Sie machen eben das
was man von ihnen erwartet. Weil die Definition einer Variable (das
Lable) nicht nur die Ramadresse enthält ,sondern auch den Variabeltyp,
lösen die Befehle lds und sts Fehlermeldungen aus. Ich habe die deshalb
durch _lds und _sts ersetzt um sie wieder in den Zahlen Bereich 0 bis
0xffff zurückzuholen. Das ist aber auch das einzig unschöne daran.
Ich habe das dseg übrigens noh nicht mit hochgeezählt. Werde ich aber
machen. Der Grund dafür ist, dass ich schon ewig mit einem Praeprozessor
arbeite, der das dseg überflüssig macht.
Weil mich das mit dem _lds und _sts genervt hat, habe ich sie bei mir in
der avrasm2.exe geändert. Damit kann ich weiterhin mit lds und sts
programieren und alles was ich bisher geschrieben habe unverändert
benutzen. Das ändern der exe würde aber nur jemand machen, der sich mit
meiner Lösung anfreundet.
Gruß Günter
Hallo, möglich, daß es Interessenten für die Sache gibt, will ich garnicht einschätzen. Mit macros habe ich mich angefreundet, als mir damals der C64 Macro-Assembler zugeflogen ist. Habe ich bei Bedarf eingesetzt und eben als include-File gesammelt. Genauso wie oft verwendetet Sachen, die dann in subroutinen.inc oder uart.inc usw. gelandet sind. War dann beim Z80 und später beim AVR nicht anders. Selbst auf den 8Bittern ist Rechenzeit selten so knapp, das man auf Funktioenn verzeichtet hat und lieber inline eingebaut hat oder soger Schleifen ausgerollt hat. Inzwischen bin ich weit mehr bei C gelandet, auf einem ESP8266 oder ESP32 möchte ich auch nicht wirklich in ASM schreiben. ;) Viel Spaß auch weiterhin, bei mir ist es inzwischen ja "nur" Rentnerhobby. Gruß aus Berlin Michael
Hallo Günter, schön daß Du es hier verständlicher erklärst. Ok, mit Günter S. schrieb: > kleines Beispiel: Du willst eine 32 Bit Zahl im Ram mit 100 addieren. > > .dseg > Lable Byte 4 > .cseg > .... > ldi r16,100 > lds r17,Labele > add r17,r16 > sts r17,Lable ..... > sieht bei mir so aus: > _long Lable .... > _addi Lable,100 sparst Du jetzt zwei Zeilen ein (mal von abgesehen dass der Asm Code oben gerade nur 8bittig rechnet). Nachteile hat das in meinen Augen gleich ist in mehrfacher Sicht: Erstens pumpt das den Programmcode nur (um die ganzen Makro-Definitionen) auf. Die Makros muss man zweitens richtig kennen und anzuwenden wissen. Drittens ist mir ein call add32 wesentlich eindeutiger und transparenter als zusätzlich neue Befehle zwischen purem Asm-Code, wie _addi Lable,100 usw. Mit der Einführung von weiterer Bürokratie wie Variablentypen verkomplizierst Du den Code (mit eigentlich gegenteiliger Absicht) weiter. Lass es mich so sagen: Ich programmier Asm nicht unbedingt, um das effizienteste Ergebnis zu erhalten (natürlich mit allen Chancen darauf) sondern weil der Code von den paar Prozessorbefehlen abgesehen so schön klar und frei von Programmierbürokratie aller Art ist. Evtl. noch ein .org, die .equ's und .db's, ein .dseg oder .eseg zieren das Ganze. 100% des Codes und seiner Funktionalität liegen vor Augen, nichts ist durch irgendwelche Winkelzüge und über 3 Ecken denkend verborgen. Nach 27 Jahren sollte man dann auch Besonderheiten von lds/sts, in/out auf seinem Ziel-AVR im Schlaf beherrschen. Grundsätzlich sind Programmiersprach-Autoren stets bemüht, ihr Werk mit immer mehr zusätzlichen Funktionen aufzupimpen. Abläufe damit zu vereinfachen. Die Featuritis-Medaille hat aber zwei Seiten. Das Ganze wird immer komplizierter anzuschaun und anzuwenden. Langt es denn nicht, daß man mit kleinteiligem Asm-Code bereits selber schon sehr filigrane und ausgefeilte Werke vollbringen kann? :) > Wenn Du dir im Reassembler anschaust, was aus den beiden Zeilen wurde, > wirst Du genau das finden, was Du sonst mit vielen Befehlen schreibst. > Ich denke, die Lesbarkeit hat damit nicht eingebüßt. davor und danach > kann ich wie gewohnt in assembler weiter programieren. die Befehle > _input und _print haben primär nichts damit zu tun. Sie machen eben das > was man von ihnen erwartet. Weil die Definition einer Variable (das > Lable) nicht nur die Ramadresse enthält ,sondern auch den Variabeltyp, > lösen die Befehle lds und sts Fehlermeldungen aus. Ich habe die deshalb > durch _lds und _sts ersetzt um sie wieder in den Zahlen Bereich 0 bis > 0xffff zurückzuholen. Das ist aber auch das einzig unschöne daran. > Ich habe das dseg übrigens noh nicht mit hochgeezählt. Werde ich aber > machen. Der Grund dafür ist, dass ich schon ewig mit einem Praeprozessor > arbeite, der das dseg überflüssig macht. > Weil mich das mit dem _lds und _sts genervt hat, habe ich sie bei mir in > der avrasm2.exe geändert. Damit kann ich weiterhin mit lds und sts > programieren und alles was ich bisher geschrieben habe unverändert > benutzen. Das ändern der exe würde aber nur jemand machen, der sich mit > meiner Lösung anfreundet. > Gruß Günter
Hallo Rich Ich muss dir größtenteils beipflichten. Das Projekt ist aber nicht dazu gedacht, quer durch das Programm, das du schreibst, Anwendung zu finden. Daß die Macros den Code aufpumpen stimmt so nicht. Wenn kein Macro aufgerufen wird, kommt auch nichts an Programm Code hinzu. Ich selbst bin übrigens auch kein Freund von kompliziertem Syntax. Aber wenn ich z.b ein Menu programiere evtl sogar mit Untermenus, tue ich mich schwer, wenn ich keine Variabeln habe. Für solche oder ähnliche Aufgaben habe ich dieses Projekt geschrieben. Mein Beispiel ist natürlich sehr einfach gehalten, um klar zu zeigen, was das Ganze eigentlich soll. Aber wenn Du z.b. eine Funktion mit Multiplikationen und Aditionen aufrufst (um dich durch ein Variabel Feld zu bewegen, musst Du dir doch ein paar Gedanken machen. Klar geht`s auch mit einfachen rcall`s. Ich bin mal gespannt, wie andere darüber denken. Gruß Günter
Angehängte Dateien:
-
Unknown_.jpg
20 KB
Hi, kenne den Befehl nicht. Und der Assembler offenbar auch nicht. ldi mit Unterstrich davor. Und für andere Targets außer dem 644-er? Portierempfehlung? ciao gustav
Günter S. schrieb: > Daß die Macros den Code aufpumpen stimmt so nicht. > Wenn kein Macro aufgerufen wird, ... ist das nicht Sinn der Sache. Beim Inkludieren kommt der Definitionstext aber mit hinzu und gehört zum Programm, egal in welchen konkreten Bytes im .hex File sich das dann niederschlägt. > Aber wenn ich z.b ein Menu programiere evtl sogar mit > Untermenus, tue ich mich schwer, wenn ich keine Variabeln habe. Für > solche oder ähnliche Aufgaben habe ich dieses Projekt geschrieben. Wenns Dir hilft warum nicht. Inwieweit einem zusätzlich eingeführte Features helfen ist sicher zu einem guten Teil auch subjektiv. > Klar geht`s > auch mit einfachen rcall`s. Genau. Klar gehts auch einfach :)
Hallo Karl bei dem _ldi handelt es sich um ein Macro welches einen 16 Bit wert in ein Index Register lädt. zb. _ldi z,1000 kannst du mit den Befehlen ldi zh,high(1000) und ldi zl, low(1000) ersetzen. Dann kennt es Dein Assembler auch ohne Macro. Klar kannst Du jeden Port nehmen um dein LCD anzusteuern. Aber nebenbei: die LCD Routine ist für Hapsim ausgelegt. Die Warte Zeiten sind zurückgesetzt, um im Simulator nicht darauf warten zu müssen. Gruß Günter
Funktioniert das Ganze auch mit der Assembleroption '-c'?
Für mich hört sich das nach einer - vielleicht verständlichen - Beschäftigungstherapie an. Falls du die Programmiersparache Forth nicht kennst, dann solltest du da mal nach schaun. Falls du sie kennst und dennoch mit Macros rumspielen willst, dann bitte schön... Wenn ich auf einem 8-Bitter 32bit-Multiplikation brauche, dann schreibe ich kein Macro, sondern ein "sauberes" Unterprogramm! Gruß Rainer
Rainer V. schrieb: > Für mich hört sich das nach einer - vielleicht verständlichen - > Beschäftigungstherapie an. +1
Zumal es fraglich ist ob der so "generierte" Code am Ende effizienter als das ist, was ein C-Compiler mit Optimierung erzeugt. Ich denke da z.B. an Sonderfälle die einfachere Operationen erlauben oder auch an Optimierung in Schleifen (Verwendung von Registern anstatt Speicher für "Variablen"). Wenn man mit Assembler programmiert, sollte man m.E. auch IN Assembler programmieren und nicht versuchen, solche Konstrukte wie Variablen herbei zu makrofizieren. An Makros für einfache 16/32 Bit Operationen auf einer 8 Bit CPU gibt es nicht auszusetzen. Kompliziertere Sachen natürlich immer in Funktionen. Eigentlich habe ich in meinen Assemblerprogrammen wirklich sehr wenige absolute Variablen verwendet. Das meiste implementiert man doch sowieso mit Strukturen (also indirekter Adressierung mit Offset). Und in Funktionen versucht man eh soviel wir möglich nur in Registern zu machen aus Geschwindigkeitsgründen. Vorher alle Register die verändert werden auf den Stack sichern (je nach Konvention...) und los gehts... Das war auf dem 6502 natürlich schwer mit Akku, X-und Y-Register, aber seit dem M68k habe ich nur so programmiert, auf dem AVR geht das auch gut.
:
Bearbeitet durch User
Hallo zusammen Ich stelle fest, dass es momentan in erter Linie hier um die Frage geht, ob der Einsatz von Macros in der Asm Programierung sinnvoll ist. Da gehen die Meinungen selbstverständlich klar auseinander. Macros haben klare Nachteile: Zum Einen ergeben sich abstruse Fehlermeldungen wenn der Aufruf nicht korrekt ist. Zum Zweiten binden sie bei jedem Aufruf die darin enthaltenen asm Befehle ins Programm ein (sonst aber nichts!). In erster Linie sollen sie dazu dienen, die Registerübbergabe für Unterroutinen zu übernehmen. Und so setze ich sie auch meistens ein. Die Frage ob man ASM oder andere Sprachen einsetzt , drängt sich natürlich auf, stand aber ursprünglich nie zur Debatte. Im Betreff steht doch klar das Wort "assemler". Ich habe auschließlich beabsichtigt, ein paar Dinge in der ASM Programierung zu vereinfachen. Also: Für alle die mit Macros auf Kriegsfuß stehen ist der Beitrag nicht von Interresse. Falls es Leute gibt, welche gerne Macros einstzen und sich mal genauer anschauen, was meine Macros hier tatsächlich an Code einbinden, und und diese evtl einzusetzen oder verbessern möchten, werde ich gerne hier weiter diskutieren. . Ich sage trotzdem mal ein Danke, für alle die sich bisher damit aueinandergesetzt haben. Gruß Günter
Günter S. schrieb: > Im Betreff steht doch klar > das Wort "assemler". Es nennt sich Assembler Günter. Manche Dinge bleiben wohl selbst nach 27 Jahren unbemerkt :)
Günter S. schrieb: > Macros haben > klare Nachteile: Zum Einen ergeben sich abstruse Fehlermeldungen wenn > der Aufruf nicht korrekt ist. Das fällt vor allem deshalb schwer ins Gewicht weil diverse Fehlermeldungen des Avrasm2 auch so schon von abstrus unklar bis falsch reichen können, je nach Verursacher. > In erster Linie sollen sie dazu dienen, die Registerübbergabe für > Unterroutinen zu übernehmen. Kann man machen. Zu den bereits genannten Preisen. Wer Assembler ein Stück weit Richtung (eigener) Hochsprache entwickeln möchte für den sind Makros natürlich ideal.
Günter S. schrieb: > ob der Einsatz von Macros in der Asm Programierung sinnvoll ist. Da > gehen die Meinungen selbstverständlich klar auseinander. Das stimmt schon mal nicht. Jeder der ernsthaft in Assembler programmiert, hat eine Sammlung von Macros (ob eigene oder kopierte, ist schon mal egal). Günter S. schrieb: > In erster Linie sollen sie dazu dienen, die Registerübbergabe für > Unterroutinen zu übernehmen. Und so setze ich sie auch meistens ein. Das stimmt auch nicht. Macros sollen einem die Arbeit abnehmen und Code übersichtlicher machen. Ich habe z.B. folgende Macros aus alten .asm Files ausgegraben:
1 | .macro SetRamBit ; RamAdr, BitPos |
2 | .macro SkipIfRamBitSet ; RamAdr, BitPos |
3 | .macro IncRamAdr ; RamAdr |
4 | .macro CmpRamAdr ; RamAdr, FixValue |
5 | etc. |
Und ich habe heute noch keinen Problem zu verstehen, was diese Macros tun. Wenn im Programm folgendes steht:
1 | SkipIfRamBitSet Flag_GPS, GpsMsgRdy |
dann muss ich nicht erst lange rumrätseln was das ist und wozu es dient. Bei deinem Beispiel aber schon. > Macros haben > klare Nachteile: Zum Einen ergeben sich abstruse Fehlermeldungen wenn > der Aufruf nicht korrekt ist. Zum Zweiten binden sie bei jedem Aufruf > die darin enthaltenen asm Befehle ins Programm ein (sonst aber nichts!). Was heisst "sonst aber nichts!" ?
:
Bearbeitet durch User
Marc V. schrieb: > Jeder der ernsthaft in Assembler programmiert, hat eine Sammlung von > Macros (ob eigene oder kopierte, ist schon mal egal). Blödsinn. Daran besteht weit und breit keine Notwendigkeit.
R.H. schrieb: > Blödsinn. Daran besteht weit und breit keine Notwendigkeit. Sehe ich genauso! Auch ich habe keine Sammlung von Macros, sondern eine Sammlung von Unterprogrammen...mit genau beschriebener Schnittstelle...Aber jeder wie er will :-) Gruß Rainer
Günter S. schrieb: > kinderleichtes assemler programieren mit > Variabeln + Rechenfunktionen Ich glaube, die Idee hatten vorher schon andere. ;-) die haben das dann C genannt ;-)
> Günter S. schrieb: > ob der Einsatz von Macros in der Asm Programierung sinnvoll ist. Da > gehen die Meinungen selbstverständlich klar auseinander. Marc V. schrieb: > Das stimmt schon mal nicht. Jeder der ernsthaft in > Assembler programmiert, hat eine Sammlung von Macros. Interessant, du glaubst also, die Meinung und Arbeitsweise aller ernsthaften Assembler Programmierer zu kennen. Wie viele sind das wohl: einer?
Hallo zusammen Ich hatte doch darum gebeten, diese Diskusion über die Frage: Macros ja oder nein, hier nicht zu diskutieren. Dass die Idee, über Macros und Praeprozessor eine Hochsprache zu realisieren nicht neu ist ist mir übrigens bekannt. Doch im vergleich zu c will ich eben den umgekehrten Weg gehen. Also nicht eine Assembler Option in eine Hochsprache einbinden, sondern die Option, Teile einer "Hochsprache" in Assembler einzubinden. Also nochmal: Bitte keine Diskusion mehr bzg. der Macros. Gruß Günter
Günter S. schrieb: > Falls es Leute gibt, welche gerne Macros einstzen und > sich mal genauer anschauen, was meine Macros hier tatsächlich an Code > einbinden, und und diese evtl einzusetzen oder verbessern möchten, werde > ich gerne hier weiter diskutieren. Das sind dann die C Programmierer. ;->>>
Günter S. schrieb: > Ich hatte doch darum gebeten, diese Diskusion über die Frage: Macros ja > oder nein, hier nicht zu diskutieren. Ich verstehe nicht. Dein Konzept beruht doch auf Makros, und du wolltest doch dein Konzept diskutieren. Oder nicht?
Rainer V. schrieb: > sondern eine > Sammlung von Unterprogrammen Hi, die sogenannten "include files". Völlig aus der Mode gekommen. Weil die "defs" vorher stimmen müssen. Weiß bloß nichtmehr, wie man die dann ins Programm reinhängt. Mit .include Pfad Dateiname oder so. ciao gustav
Karl B. schrieb: > Weiß bloß nichtmehr, wie man die dann ins Programm reinhängt. > Mit .include Pfad Dateiname oder so. Ja, macht(e) man so...bei richtig umfangreichen Programmen. Für "normale" Anwendungen reicht schon ein "Copy/Paste". Bei hardwarenaher Programmierung muß man doch eh nachsehen, ob die Def's stimmen. Sehe nicht, wie das durch ein Macro verbessert werden könnte...um mal beim Thema zu bleiben :-) Gruß Rainer
Karl B. schrieb: > die sogenannten "include files". > Völlig aus der Mode gekommen. > Weil die "defs" vorher stimmen müssen. Weder ist da was aus der Mode gekommen noch müssen irgendwelche defs stimmen oder wären überhaupt erforderlich. .include "Datei.xxx" hängt den Inhalt der Datei (aus dem Verzeichnis der assemblierten Hauptdatei, sonst mit Pfadangabe) schlicht genau da rein wo die Anweisung steht. Mehr passiert da nicht. Kann man zum Beispiel machen um seinen Code funktionell zu gliedern.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.