This page (revision-21) was last changed on 03-Feb-2023 15:21 by Florian Dingler 

This page was created on 20-Feb-2010 19:38 by Carsten Strotmann

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
21 03-Feb-2023 15:21 20 KB Florian Dingler to previous

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 15 changed one line
In vielen ACTION!-Listings, die in amerikanischen Zeitschriften zu finden waren, wurden eifrig PEEK- und POKE-Befehle eingesetzt. Das zeigt, dass die Autoren noch nicht erkannt haben, welche eleganten und leistungsfähigen Konstruktionen ACTION! anbietet und damit PEEK und POKE vollkommen überflüssig werden lässt. Nehmen wir als Beispiel nut die Abfrage eines Joysticks über die Speicherzelle 632 (STICK0). Ein Test auf die Mittelstellung könnte lauten:
In vielen ACTION!-Listings, die in amerikanischen Zeitschriften zu finden waren, wurden eifrig PEEK- und POKE-Befehle eingesetzt. Das zeigt, dass die Autoren noch nicht erkannt haben, welche eleganten und leistungsfähigen Konstruktionen ACTION! anbietet und damit PEEK und POKE vollkommen überflüssig werden lässt. Nehmen wir als Beispiel nut die Abfrage eines Joysticks über die Speicherzelle 632 ([STICK0]). Ein Test auf die Mittelstellung könnte lauten:
At line 46 changed one line
Wieder ist das Ergebnis selbst in Assembler kaum schneller zu programmieren. Lässt man jedoch den Zusatz „(0)“ weg, wir der Compiler annehmen, dass es sich auch um ein längeres Feld handeln könnte und muss daher zur indirekten Adressierung greifen. Dazu wird bei der Definition ein Zeiger auf das Array angelegt, der bei der Verwendung erst in die Zero-Page verlagert werden muss. Nur dort kann der 6502 indirekte Adressierungsarten ausführen. Das Ergebnis sähe dann so aus:
Wieder ist das Ergebnis selbst in Assembler kaum schneller zu programmieren. Lässt man jedoch den Zusatz "(0)" weg, wird der Compiler annehmen, dass es sich auch um ein längeres Feld handeln könnte und muss daher zur indirekten Adressierung greifen. Dazu wird bei der Definition ein Zeiger auf das Array angelegt, der bei der Verwendung erst in die Zero-Page verlagert werden muss. Nur dort kann der 6502 indirekte Adressierungsarten ausführen. Das Ergebnis sähe dann so aus:
At line 61 changed one line
Sie sehen schon, das ist ungleich aufwendiger und daher auch viel langsamer (aber dennoch schneller als der ursprüngliche POKE-Befehl). Kurze Byte Arrays sollten Sie daher immer mit „(0)“ definieren. Die lange „Zeiger“-Definition braucht man nur bei umfangreichen Feldern (ab 256 Bytes) oder falls das Feld während des Programmlaufes auf eine andere Adresse gelegt werden soll (auch das kann ACTION!).
Sie sehen schon, das ist ungleich aufwendiger und daher auch viel langsamer (aber dennoch schneller als der ursprüngliche POKE-Befehl). Kurze Byte Arrays sollten Sie daher immer mit "(0)" definieren. Die lange "Zeiger"-Definition braucht man nur bei umfangreichen Feldern (ab 256 Bytes) oder falls das Feld während des Programmlaufes auf eine andere Adresse gelegt werden soll (auch das kann ACTION!).
At line 63 changed one line
Vielleicht noch eine Anmerkung für all diejenigen Leser, denen Felder ohne Längenangabe noch „spanisch“ vorkommen. Der ACTION!-Befehl ARRAY wirkt wie die DIM-Anweisung in BASIC, nur DIM ist wesentlich weniger flexibel, da es dem Programmierer alle Arbeit abnimmt. Bei ARRAY kann man selbst bestimmen, wo das Feld im Speicher liegen soll, aber man ist auch für alle Konsequenzen selbst verantwortlich. So finden keinerlei Überprüfungen der Index-Grenzen statt, und wenn man sein Array so legt, dass lebenswichtige Zellen des Computers überschrieben werden, so hilft eben nur noch der Reset-Knopf. Damit erklären sich auch so anscheinend sinnlose Definitionen, wie es ein Feld mit der Länge Null oder ohne Längenangabe ist. Dies ist nur als ein Zeichen für den Compiler zu verstehen, der Programmierer muss schließlich selbst über die tatsächliche Länge wachen.
Vielleicht noch eine Anmerkung für all diejenigen Leser, denen Felder ohne Längenangabe noch "spanisch" vorkommen. Der ACTION!-Befehl ARRAY wirkt wie die DIM-Anweisung in BASIC, nur DIM ist wesentlich weniger flexibel, da es dem Programmierer alle Arbeit abnimmt. Bei ARRAY kann man selbst bestimmen, wo das Feld im Speicher liegen soll, aber man ist auch für alle Konsequenzen selbst verantwortlich. So finden keinerlei Überprüfungen der Index-Grenzen statt, und wenn man sein Array so legt, dass lebenswichtige Zellen des Computers überschrieben werden, so hilft eben nur noch der Reset-Knopf. Damit erklären sich auch so anscheinend sinnlose Definitionen, wie es ein Feld mit der Länge Null oder ohne Längenangabe ist. Dies ist nur als ein Zeichen für den Compiler zu verstehen, der Programmierer muss schließlich selbst über die tatsächliche Länge wachen.
At line 67 changed one line
Letzte und universelle Möglichkeit zum Ersetzten von PEEK und POKE bietet der Pointer. Derartige Zeiger-Variablen enthalten eine Adresse einer anderen Variablen oder einer beliebigen Speicherzelle. Basic-Kenner werden jetzt einwerfen, dass daran nichts Besonderes ist, schließlich kann jede normale Variable auch eine Adresse enthalten. Wozu also Pointer? Diese Spezial-Variablen haben Fähigkeiten, die über das normale Maß hinausgehen. So kann durch das Anfügen des Pointer-Symboles „^“ der Inhalt der Variablen erreicht werden, auf die der Pointer zeigt. Sehen Sie sich das gleich an einem Beispiel an:
Letzte und universelle Möglichkeit zum Ersetzten von PEEK und POKE bietet der Pointer. Derartige Zeiger-Variablen enthalten eine Adresse einer anderen Variablen oder einer beliebigen Speicherzelle. Basic-Kenner werden jetzt einwerfen, dass daran nichts Besonderes ist, schließlich kann jede normale Variable auch eine Adresse enthalten. Wozu also Pointer? Diese Spezial-Variablen haben Fähigkeiten, die über das normale Maß hinausgehen. So kann durch das Anfügen des Pointer-Symboles "^" der Inhalt der Variablen erreicht werden, auf die der Pointer zeigt. Sehen Sie sich das gleich an einem Beispiel an:
At line 130 changed one line
Wer das ACTION!-Handbuch (Seite 144) genau gelesen hat, weiß, dass die Adresslage des erzeugten Objektprogramms mit den Speicherzellen $0E, $0F und $491, $492 gesteuert werden kann. Durch geschickte DEFINEs kann man sich quasi zusätzliche Befehle zum Verändern der Adressen schaffen. Die neue Anweisung ZEROPAG verlagert alle nachfolgenden Definitionen in die Zero-Page. Da es dort recht eng zugeht, sollten Sie nur wichtige und häufig benutzte Variablen dahin legen. Sie dürfen auch niemals vergessen, die Adresslage nach den Definitionen mit RESTORE wieder in einen „normalen“ Bereich zurückzulegen. In Listing 1 finden Sie auch gleich ein Beispiel für die Definition eines Pointers in der Seite Null.
Wer das ACTION!-Handbuch (Seite 144) genau gelesen hat, weiß, dass die Adresslage des erzeugten Objektprogramms mit den Speicherzellen $0E, $0F und $491, $492 gesteuert werden kann. Durch geschickte DEFINEs kann man sich quasi zusätzliche Befehle zum Verändern der Adressen schaffen. Die neue Anweisung ZEROPAG verlagert alle nachfolgenden Definitionen in die Zero-Page. Da es dort recht eng zugeht, sollten Sie nur wichtige und häufig benutzte Variablen dahin legen. Sie dürfen auch niemals vergessen, die Adresslage nach den Definitionen mit RESTORE wieder in einen "normalen" Bereich zurückzulegen. In Listing 1 finden Sie auch gleich ein Beispiel für die Definition eines Pointers in der Seite Null.
At line 153 changed 2 lines
INCLUDE „RUN1.ACT“
INCLUDE „RUN2.ACT“
INCLUDE "RUN1.ACT"
INCLUDE "RUN2.ACT"
At line 166 changed one line
Ich hoffe, dass die Assembler-Fans nicht verärgert sind, weil es diesmal eine reine ACTION!-Ecke geworden ist. Ich glaube aber, dass sich inzwischen auch viele ML-Freaks mit Sprachen wie ACTION! beschäftigen und die Assemblerecke auch ein Forum für assemblernahe Sprachen sein sollte. Zum Trost: in der nächsten Ausgabe gibt’s wieder reichlich Futter für den Assembler.
Ich hoffe, dass die Assembler-Fans nicht verärgert sind, weil es diesmal eine reine ACTION!-Ecke geworden ist. Ich glaube aber, dass sich inzwischen auch viele ML-Freaks mit Sprachen wie ACTION! beschäftigen und die Assemblerecke auch ein Forum für assemblernahe Sprachen sein sollte. Zum Trost: in der nächsten Ausgabe gibt's wieder reichlich Futter für den Assembler.