letzter Beitrag von ogd am
Was mir immer wieder fehlt und ich nicht verstehe warum man das nicht auch in C compiler eingebaut hat ist dass man ein binary include machen kann. Also dass man eine binardätei einem Label zuweisen kann und die Daten mit einem include einbinden kann.
Bei Assemblern wird das manchmal unterstützt, aber auch nicht alle, obwohl das was ist, was man immer wieder brauchen kann.
Ich finde : hinter dem label sehr hilfreich wenn man im Quelltext danach sucht. Sonst trifft man ja auch auf saemtliche Referenzen.
Was mir immer wieder fehlt und ich nicht verstehe warum man das nicht auch in C compiler eingebaut hat ist dass man ein binary include machen kann. Also dass man eine binardätei einem Label zuweisen kann und die Daten mit einem include einbinden kann.
Bei Assemblern wird das manchmal unterstützt, aber auch nicht alle, obwohl das was ist, was man immer wieder brauchen kann.
Braucht man nicht wirklich. Ein Programm um eine Binärdatei in C oder ASM Datenkommandos zu konvertieren ist schnell geschrieben.
Braucht man nicht wirklich. Ein Programm um eine Binärdatei in C oder ASM Datenkommandos zu konvertieren ist schnell geschrieben.
Ja, sicher ist es das. Aber das ist umständlich und erfordert ein zusätzlichen Buildschritt. Genaus könnte man auch sagen dass überhaupt kein Include braucht, denn das Argument ist das Gleiche. Ein Programm das alle Textfiles zusammenmerged vor dem übersetzen ist auch schnell geschrieben.
Bla. Im Makefile 1x dazugetan braucht man nicht mehr darüber nachdenken...
Was mir immer wieder fehlt und ich nicht verstehe warum man das nicht auch in C compiler eingebaut hat ist dass man ein binary include machen kann.
Binärdateien zusammensetzen ist eher Job des Linkers, bei einer gcc/GNU-Toolchain kann man das zB mit einem angepassten Linkerscript erreichen oder man verwendet "objcopy -I binary -O elf<irgendwas-passendes-zur-architektur> input.bin input.o" um aus der Binärdatei ein Objectfile zu machen, dann werden automatisch Symbole "_binary_input_bin_(start/end/size)" erzeugt um die Daten referenzieren zu können.
Viel lustiger wird es, wenn man zusätzlich zu dem Assembly auch noch eine Sourcemap braucht.
Welche Adresse entspricht welcher Zeile (eine Zeile kann mehrfach verwendet werden, etc.), Macros und Loops vervielfältigen Code, etc.
Du musst aber im Programmcode im ersten Pass den Platz für die Parameter vorsehen. Weil davon hängen alle weiteren Programmadressen ab. Du kannst nicht nachträglich erst enscheiden, ob das ein Ein-Byte oder Zwei-Byte-Adresse ist.
Nicht unbedingt. Man kann die eine oder andere Annahme treffen und dann noch einen weiteren Pass anhängen, der versucht das zu begradigen. Ich glaub ACME macht das so. Damit könnten natürlich auch unentscheidbare Situationen entstehen, wo mit der Änderungen in einem Fall ein anderer "auf" geht und immer dazwischen hin und her gesprungen wird, was immer zu einem neuen Pass führt ... das muss man halt mit einem maximalen Passcount abfangen, was dann manuell aufgelöst werden müsste.
Zu komplex mit dem Auflösen. Wenn du bei einer neuen Zeile die Adresse nicht weisst, hast du bei sowas wie !if * > $2000 z.Bsp. verloren. Das gibt so viele mögliche Kombinationen, die alle durchzuspielen um die "beste" zu bestimmen, dann dauert das Assemblieren etwas länger 
(Ich habe den Verdacht, dass Exomizer sowas versucht, anders kann ich mir fast nicht erklären, warum der für <64kB gefühlt sehr lange braucht)
Nicht unbedingt. Man kann die eine oder andere Annahme treffen und dann noch einen weiteren Pass anhängen, der versucht das zu begradigen. Ich glaub ACME macht das so. Damit könnten natürlich auch unentscheidbare Situationen entstehen, wo mit der Änderungen in einem Fall ein anderer "auf" geht und immer dazwischen hin und her gesprungen wird, was immer zu einem neuen Pass führt ... das muss man halt mit einem maximalen Passcount abfangen, was dann manuell aufgelöst werden müsste.
Da kommen wir jetzt wieder in den Bereich des Overengineering. Natürlich kann man das machen mit beliebig viel Aufwand. Aber wie oft kommt es vor, dass man das braucht?
Als Assemblerprogrammierer will ich doch wissen, was der Assembler tut und das nach klaren Regeln. Und wenn der mir ein Abs erzeugt wo ich eigentlich ein ZP haben möchte (oder umgekehrt), dann sorge ich einfach dafür, dass die Labels vorher entsprechend definiert sind. Fertig, Problem gelöst.
Außerdem kann man bei meinem Assembler auch noch die Größe des Arguments explizit vorgeben (mit den Keywörtern ABS und ZP). Denn manchmal will man tatsächlich ein Abs obwohl ein ZP möglich wäre. Und wenn man ein ZP verlangt und der Wert passt dann nicht rein, gibt es eine Fehlermeldung.
Wenn 'label' noch nicht definiert wurde, könnte es ja auf der Zero-Page liegen oder nicht.
Also ein lda $01,y ($B6 mit 2 Bytes) oder ein lda $1000,y ($B9 mit 3 Bytes) werden.
Alternativ könnte es auch noch lda $0001,y sein.
Das ist ja egal. Es geht nur darum, ob man im ersten Pass ein oder zwei Byte für die Adresse reservieren muss. Im zweiten Pass muss der Wert ja dann definiert sein.
Worauf ich hinaus wollte war, dass es nicht trivial ist, zu entscheiden, ob ein Befehl die Zeropage addressiert oder nicht. Bei lda $0001,y könnte man versucht sein, den 2-Byte-Befehl zu verwenden. Der User könnte aber den 3-Byte-Befehl gemeint haben, weil das bei timing-kritischen Programmen einen Unterschied macht.
Wenn die Zahl jetzt stattdessen ein Label ist (am besten mit einer komplizierten Berechnung), wie soll der Assembler dann noch rausfinden, welche Version der User sich wünscht...
Worauf ich hinaus wollte war, dass es nicht trivial ist, zu entscheiden, ob ein Befehl die Zeropage addressiert oder nicht. Bei lda $0001,y könnte man versucht sein, den 2-Byte-Befehl zu verwenden. Der User könnte aber den 3-Byte-Befehl gemeint haben, weil das bei timing-kritischen Programmen einen Unterschied macht.
Wenn die Zahl jetzt stattdessen ein Label ist (am besten mit einer komplizierten Berechnung), wie soll der Assembler dann noch rausfinden, welche Version der User sich wünscht...
Die Regel ist ganz einfach: Wenn der Wert das Labels <= $FF ist, dann wird ZP-Adressierung verwendet. Weil das in 99,9% der Fälle das ist, was der Programmierer will. Wenn er was anderes will, dann schreibt er bei meinem Assembler ein ABS vor das Argument.
Das sieht dann zum Beispiel so aus: STA ABS,label
Beim Label löst man (d.h. ich) so, ist der Wert des Labels bekannt, und <= $ff, dann zeropage, sonst die absolute Variante (oder +1 / +2 um es zu erzwingen: sta+2 label)
Kommt dann auch auf den Assembler an. CA65 verlangt den, andere wohl nicht.
Nicht, wenn du ihn mit `--feature labels_without_colons aufrufst... 
Viel lustiger wird es, wenn man zusätzlich zu dem Assembly auch noch eine Sourcemap braucht.
Welche Adresse entspricht welcher Zeile (eine Zeile kann mehrfach verwendet werden, etc.), Macros und Loops vervielfältigen Code, etc.
Ach, wer braucht das schon außer den Wahnsinnigen, die eine IDE für Assembler schreiben 
.
Ach, wer braucht das schon außer den Wahnsinnigen, die eine IDE für Assembler schreiben
Die Wahnsinnigen die eine IDE nutzen.
Ich finde : hinter dem label sehr hilfreich wenn man im Quelltext danach sucht. Sonst trifft man ja auch auf saemtliche Referenzen.
Genau so ist es
Wenn ich bei der Suche den Doppelpunkt angebe, so kann ich von Label zu Label springen.
Für mich ist das ist eine große Hilfe.
Ich hab mir ein Syntax-Highlighting gebaut, das durch den Doppelpunkt Labels erkennt. Daher benutze ich ihn konsequent. So ist er zumindest zu überhaupt etwas nütze
Selbst ohne Highlightning finde ich mit Doppelpunkt leserlicher, als ohne.
Ich finde : hinter dem label sehr hilfreich wenn man im Quelltext danach sucht. Sonst trifft man ja auch auf saemtliche Referenzen.
bspw.
Hm... Die Suche nach
findet das Label 'abel' am Zeilenanfang auch. (vim-Syntax)
Was ist mit
label EQU 17
Das erlauben die meisten Assembler auch ohne Doppelpunkt, selbst wenn sie sonst einen wollen.
Das ist IMHO einfach Geschmacks- und Übungssache. Sonst fordere ich einen Assembler, bei dem die Label in Spalte 1, die Mnemonis in Spalte 8 und die Operanden ab Spalte 12 erwartet werden.
Ich finde : hinter dem label sehr hilfreich wenn man im Quelltext danach sucht. Sonst trifft man ja auch auf saemtliche Referenzen.
Das ist tatsächlich ein sinnvolles Argument für den ':'.
