An die Stellen muss er nicht springen, da es sich nicht um einen Programm-Sprung handelt. Es ist zwar ein Bereich im Programm-Speicher, der eigentlich Wort-weise organisiert ist, es werden aber nur die Daten an der Stelle über Z-Register und "lpm" geladen, wobei dann Byte-weise zugegriffen werden kann. Die gelesenen Werte (zwei Bytes) geben die tatsächliche Sprungadresse an, an die gesprungen werden soll (über Z-Register und "icall"). Insgesamt ist das Ding einfach eine statische Tabelle, wo für bestimmte Taster-Kombinationen (in einem Byte kodiert), Sprungadressen hinterlegt sind. Das System funktioniert ja, wenn ich "HIGH(jump_adr1),LOW(jump_adr1)" schreibe. Es ist also einfach eine Frage der Übersichtlichkeit und Wartbarkeit, wenn ich stattdessen "LWRD(jump_adr1)" schreiben könnte (an der Tabelle, von denen es sogar mehrere je nach internem Programm-Zustand gibt, muss ich noch einige Male herumschrauben, während das Programm wächst). Die Labels sind der Aussagekraft wegen außerdem nicht so kurz wie hier im Beispiel, was das ganze nochmal aufbläht.

Makros habe ich an der Stelle nicht zum Laufen gebracht. Die verwirren den Compiler.

Gut, dann wäre zumindest das geklärt. Es ist also keine Sprungtabelle im eigentlichen Sinne, aber irgendwie dann doch .

sowas hier klappt nicht?

#define PG_ADDR (x) HIGH(x),LOW(x)

Ich kanns leider nicht ausprobieren, da ich den Assembler nicht habe. Ein Compiler macht was anderes.


Edit:
Kannst du nicht einfach so das Labelsymbol dort eintragen, z.B. mit label & 0xff und (label / 256) & 0xff? Oder meckert er dann?


_________________


[ Diese Nachricht wurde geändert von: DonComi am  6 Mai 2009 22:06 ]

[ Diese Nachricht wurde geändert von: DonComi am  6 Mai 2009 22:06 ]

Ja, das machts (das #define)! Danke sehr! Ich bin beim Hilfe lesen wohl immer irgendwie an der Möglichkeit vorbei gerauscht. Und nachdem Makros an der Stelle nicht funktioniert haben, habe ich aufgegeben.

Offtopic :

Ein Assembler macht doch auch nur Maschinencode aus einem Menschen "lesbaren" Code. Ein Unterschied ist da nicht wirklich. Ein Assembler ist halt ziemlich hardware-nah (obwohl man ein mit C für einen AVR geschriebenes Programm auch nur schwer portieren kann)

Moin,

Ein Assemblierprogramm ("Assembler") erzeugt doch nur aus dem menschenlesbaren Assemblersprachen-Kode den (binären) Maschinenkode. Ein Compiler übersetzt (und macht noch viel mehr) den Hochsprachenkode in einen niedrigeren, z.B. in Assemblersprache. Danach läuft der Assembler über diesen Kode und erzeugt en Maschinenkode.

Man kann den GCC so aufrufen, dass der generierte Assemblersprachenkode in eine Datei geschrieben wird. Danach bricht er ab, ruft den as nicht mehr auf. Erst dieser würde den Binärkode erstellen.

Das ist immer so ein Problem: Der Begriff "Assembler" meint dieses Programm, während es oft synonym für "Assemblersprache" oder "-dialekt" gebraucht wird.

Edit:
P.S.: Ich will hier auf keinen Fall klugscheißern. Es mag viele Compiler geben, die ihren Assembler selbst haben. (denn der kommt schließlich vor dem Linker).

Zitat :

Ein Assembler macht doch auch nur Maschinencode aus einem Menschen "lesbaren" Code. Ein Unterschied ist da nicht wirklich. Ein Assembler ist halt ziemlich hardware-nah (obwohl man ein mit C für einen AVR geschriebenes Programm auch nur schwer portieren kann)

Naja, wie oben angeklungen, ist der Unterschied zu einem Compiler enorm groß. Es gibt zwar Assembler, die etwas mehr machen als nur binär zu kodieren, aber der Compiler ist auf jeden Fall "intelligenter" als ein einfacher Assembler.
Das heißt nicht, dass dieser wenig komplex ist. Der in deinem Fall kann ja sogar C-Präprozessor-Anweisungen verarbeiten. Es wird einem also schon was abgenommen, z.B. eben das Expandieren von Makros und z.T. auch die Verwaltung des Speichers (rudimentär).



Freut mich aber, dass es geklappt hat!

_________________


[ Diese Nachricht wurde geändert von: DonComi am  7 Mai 2009  3:22 ]

Zitat :

Das heißt nicht, dass dieser wenig komplex ist.

Ich habe sogar mal auf einem x86 Macroassembler (aber nicht dem von BG) zwei Crossassembler geschrieben.
War eigentlich ganz leicht.

Moin perl,

Wieviele Zeilen waren die lang (nur Programmcode?)
Und für welche Zielarchitektur hat dein Assembler Code erzeugt?

Ich habe mal direkt in Assembler (-sprache ) einen Disassembler geschrieben. Allerdings nicht für x86 sondern für eine einfachere Architektur (AVR). Trotz kurzen Sicherungsintervalle meiner Entwicklungspartition ist der mir flöten gegangen
Sowas ist sehr ärgerlich...

_________________

Ach je, das ist wohl schon gut 25 Jahre her.
Ein paar Seiten werden es schon gewesen sein, aber praktisch nur Macros.
Ich hab das damals zuerst nur als Fingerübung für den SC/MP gemacht und kurz darauf produktionsmäßig für 8748 &Co.
Einen einfachen Assembler zu schreiben ist nicht schwer. Ein Kollege hat das damals sogar rein mit einer Macrofähigen Textverarbeitung (BG wusste da noch garnicht was das ist), für den 8085 gemacht.
Das waren sehr fortschrittliche Systeme, die wir damals den Schreibbüros der Behörden hier verkauft haben. Ausser WYSIWIG konnten die 1980 praktisch schon alles was MS-Word erst mehr als 10 Jahre später annähernd schaffte.
Ursprünglich stand Burroughs auf den Rechnern und IBM wurde mit "Imitated Burroughs Machines" übersetzt.

Nicht schlecht!
Konnte man mit dieser Textverarbeitung denn binäre Daten verarbeiten? Bevor jemand lacht, ich meine damit, mehr als nur reine Text-Dateien verarbeiten?
Irgendwie musste er ja den lauffähigen Kode zusammenbekommen.

_________________

Auch das geht, wenn man weiss wie man den Debugger aus der Textverarbeitung aufruft.
Haben wir auch gemacht, aber das war dann kein Crossassembler.
Die späteren Versionen der Textverarbeitung (auf x86 Rechnern laufend), konnte man auch regulär in einen Hex-Editor-Modus umschalten um die eigenen Files zu verhunzen.
Ausserdem war das Betriebsysstem in der Lage Textdokumente zu erkennen und hat routinemäßig fremde Programme, die mit den Formatangaben etc. nichts anfangen können, die Files ohne diese lesen lassen. Die bekamen dann also nacktes ASCII präsentiert.
Wenn man den Rucksack mit den Formatangaben auch haben wollte, musste man eine spezielle Open-Mode wählen.

Wenn man für einen anderen Prozessor Code erzeugt, braucht man ja eh noch externe Hardware, z.B. um die EPROMs zu brennen. Dann kann man auch ASCII-Daten transportieren. Die JEDEC-Files, die viele Entwicklungspakete erzeugen, sind ja nichts anderes.

Äh, klar.
Ich habe mal wieder zu komplex gedacht, nicht umsonst gibts reine ASCII-Verfahren, binäre Daten zu repräsentieren... Meine Güte, und ich komm nicht drauf, dabei arbeite ich täglich mit ihex (Intel Hex Format) ...

Ist aber auf jeden Fall interessant, was ihr da gemacht habt!

_________________