Assembler ?

[drzeissler]

Hallo,

könnte man, wenn man keine Ahnung hat Maschinensprache erlernen.
Kürzlich habe ich ein Buch in der Bucht gesehen, da wurde 8088 bis 80287
Maschinensprache angepriesen.

Eurer Einschätzung nach, kann man sowas lernen, bzw. welchen
Zeithorizont muss man dafür einplanen ?

Ich würde auch gerne ein paar Demoscene-Sachen machen die
auf einem 286 mit CoProz. laufen.

Danke Euch
Doc

[ChrisR3tro]

Hi Doc,

selbstverständlich läßt sich das erlenen, aber ich würd damit rechnen, daß man erst endlos Hello-World-Material programmiert bevor man an Demoscene-Qualität auch nur ansatzweise herankommt, zumal da immer auch noch eine ordentliche Portion Mathematik dazugehört. Das darf man nicht vergessen. Die Leute in der Demoszene haben meistens auch eine eigene "Bibliothek" an Algorithmen, die sie über die Jahre immer erweitern und wiederverwenden.

Ich habe mir selbst letztens Assembler für den AVR ATMega8-MIkroprozessor in einer Vorlesung aneignen dürfen. Es ist wirklich interessant, so maschinennah zu programmieren, aber es gibt auch eine ganze Menge Sachen zu beachten, und bei der über die Jahre gewachsenen x86-Moloch-Architektur stell' ich mir das nochmal zeitaufwendiger und langwieriger vor, bis man da alle Kniffe kennt.

Ich will dich ja jetzt nicht demotivieren oder so, aber Assembler ist halt auch eine harte Nuß.

Gruß
locutus

[wobo]

Hallo,

könnte man, wenn man keine Ahnung hat Maschinensprache erlernen.
Kürzlich habe ich ein Buch in der Bucht gesehen, da wurde 8088 bis 80287
Maschinensprache angepriesen.

Eurer Einschätzung nach, kann man sowas lernen, bzw. welchen
Zeithorizont muss man dafür einplanen ?

Ich würde auch gerne ein paar Demoscene-Sachen machen die
auf einem 286 mit CoProz. laufen.

Danke Euch
Doc

Lernen kann man das bestimmt. Den Zeitaufwand abzuschätzen, ist aber ziemlich schwierig. Neben äußeren Umständen ist das wohl auch ziemlich individuel. Der Syndicate-Programmierer z.B. hat im Handbuch zu dem Spiel geschrieben, dass er ohne irgendein Programmierwissen quasi von Null ausgehend innerhalb 2 Wochen Assembler gelernt hat und dann direkt Syndicate (zusammen mit dem Hauptprogrammierer) geschrieben hat.

Ich dagegen habe mehrere Jahre gebraucht, um ein bisserl Pascal zu lernen. Und was Ergiebiges ist so richtig noch nicht herausgekommen. Und dass ich jemals Syndicate-Niveau erreiche, ist einfach ausgeschlossen.

Deswegen: Probier´es doch einfach aus und kaufe Dir das Buch. Mit der Zeit wirst Du schon merken, ob Du mit Deinen Fortschritten zufrieden bist und weiter machen willst. Mit Porto dürfte das Buch ja nicht mehr als 10,00 Euro kosten. Und 10,00 Euro dürftest Du ja schon öfters mal in den Wind gesetzt haben. Und auch die investierte Zeit kann man anders wirklich schlimmer vertun ...

Das "Problem" beim Programmieren ist m.M. eigentlich nicht, dass man eine Programmiersprache kann, sondern dass man Probleme lösen muss. Dazu langt es meistens nicht, sich in einer Programmiersprache auszukennen.

Wenn Du z.B. Dein Buch durch hast, wirst Du deswegen wahrscheinlich noch keine Demo-Effekte schreiben können. Du brauchst dann erst noch ein Buch (o.ä.), welches z.B. die Grafikkarte beschreibt. Vielleicht musst Du auch noch ein bisschen Mathe auffrischen etc.

Wie gesagt: Wenn es Dich reizt, probiere es doch einfach aus.

[drzeissler]

klingt logisch, danke. Wie gesagt, es gibt viel zu wenig Sachen für 286/287, daher mein Antritt.
Aber das wird sicher ne Sache von x Jahren. Dennoch werde ich mal in die Materie einlesen.

Gewisse Engines gibt es ja schon, man könnte somit im Baukastenprinzip anfangen.

[freecrac]

Zum Anfang sollte man sich mit dem Hexadezimalsystem auskennen.

Als nächstes sollte man wissen das es CPU-Register gibt die Werte enthalten können und das die meisten Befehle zusammen mit dieses Registern zu verwenden sind.
Grob unterscheiden lassen sich die Register in Segmentregister, Offsetregister und Allzweckregister. Auf Segmentregister und Offsetregister kann man nur als ganzes zugreifen und dort jeweils 16 Bit(80286) lesen und schreiben.
Die Allzweck-Register "AX, BX, DX und CX" lassen sich in High-Byte und Low-Byte(AL + AH = AX) unterteilen und damit auch auf deren 8 Bit lesend und schreibend zugreifen.

Viele Befehle benutzen eine Adressierung, um auf Speicherbereiche zugreifen zu können.
Bei der x86- Architektur haben wir im Realmode mit einer segmentierten Adressierung zu tun.
Das bedeutet: Jedes Segment ist 16 Byte gross und beginnt an einer durch 16 teilbaren Adresse.
Eine Adresse kann damit über ein Segmentregister (welches den Segmentanteil einer Adresse enthält) und einem Offsetregister(welches den Offsetanteil einer Adresse enthält) gebildet werden.
Zusammen gerechnet ergibt sich daraus eine lineare Adresse= (Segmentadresse * 16) + Offsetadresse. (So eine daraus gebildetete lineare Adresse interessiert uns in der Regel nicht, weil wir es meistens nur mit dem Offset-Anteil zu tun bekomnmen und es uns dabei wenig interessiert, welche lineare Adresse wir zur Zeit verwenden. Weil wir für unsere Anwendung, je nach dem wo der nächste freie Speicher anfängt davon abhängig eine Adressen für unser Code-, Daten- und Stack-Segment von DOS zugewiesen bekommen und diese Adresse je nach geladenen Teiber und Konfiguration von DOS variert.)
Bei der Verwenndung der Offsetregister zur Adressierung muss man noch berücksichtigen dass das BP- und das SP-Offsetregister dem Stacksegment bzw. dem SS-Segmentregister standardmäßig zugeordnet sind und alle anderen Offsetregister dem Datensegment bzw. dem DS-Segmentregister zugeordnet sind. So ergeben sich folgende Kombinationsmöglichkeiten: "SS:SP" und "SS:BP" wobei hier eine Kombination von "Segmentregister:Offsetregister" gemeint wird. Die standardmäßige Zuordnung von Segment und Offset kann durch eine Segment-Override-Prefix-Segmentangabe vor dem jeweiligen Befehl ausser Kraft gesetzt werden, so das jene Segmentangabe stattdessen für die Adressierung benutzt wird.

Von zentraler Bedeutung ist das Flagregister dessen Bits/Flags durch viele Befehle gesetzt/gelöscht und auch ausgewertet und bei der Ausführung verschiedener Befehle somit berücksichtigt werden.
Vergleichsbefehle die beispielsweise zwei Registerwerte miteineander vergleichen setzen/löschen je nach Ergebniss verschiedene Flags im Flagregister.
Bedingte Sprungbefehle werten diese Flags aus und springen ggf. zu der angegebenen Adresse. Auf diese Weise läßt sich der gesamte Programm-Ablauf steuern indem darüber zu verschiedenen Routinen verzweigt wird.

Wie die verschiedenen Befehle verwendet werden, das muss im einzelnen geschaut werden. Einige Befehle verwenden eine feste Zuordnug von Registern die man für solche Befehle verwenden muss.

Bei Fagen helfe ich gerne weiter.

Edit: Eine FPU benutzt man nur wenn es nicht anders geht, weil nicht besonders schnell. Schneller geht es oft mit reinen Interger-Berechnungen durch die CPU.
Wenn es geht berechnet man schon alle Ergebnisse im voraus und legt sie in eine Tabelle, um sie dann zur Laufzeit nur noch auslesen zu müssen.
Ggf. kann man auch die Gleitkomma-Werte in einer Sinus/Kosinus-Tabelle mit 1000 multiplizieren, um daraus ganze Zahlen zu bilden.

Dirk

[drzeissler]

das klingt sehr interessant. gibt es das grafisch aufbereitet um einen überblick über das ganze zu bekommen.

danke!

[freecrac]

das klingt sehr interessant. gibt es das grafisch aufbereitet um einen überblick über das ganze zu bekommen.

danke!

Nach kurzem Suchen habe ich das hier gefunden, es macht mir auf den ersten Blick einen ganz guten Eindruck:
Einführung in die Assemblerprogrammierung mit x86-Prozessoren
http://www.borncity.com/web/Library/EinfASM.pdf

Dirk

[drzeissler]

oh ja, das sieht gut aus!
DANKE!

[DOSferatu]

Auf meiner Seite habe ich einen Text selbst verfaßt:
http://www.imperial-games.de/html/dosd2.htm
Der Text heißt "REAL MODE Beschreibung". Da werden schon einige Sachen dazu erwähnt.
Eine Liste der Befehle und auch einiges über Assembler steht in dem langen Text ASM86FAQ.TXT - ebenfalls auf besagter Seite zu finden. Dies ist aber weniger zum Lernen, sondern mehr als eine Art "Nachschlagewerk" gedacht.
Ich selbst habe hier ein Buch, das gar nicht mal so schlecht ist, wenn man mit Assembler anfangen will:
Es heißt "Maschinensprache für Einsteiger", geschrieben von Holger Schäkel.
Von Data Becker, ISBN 3-89011-303-6
(Einführung in die Assemblerprogrammierung von 8086 bis 80486.)
Hat damals 49 DM (ja, Westgeld!) gekostet.
Keine Ahnung, ob es das heute noch gibt, ich habe das schon sehr lange.
Ich persönlich fand es recht informativ. Aber ich habe mich dann später auch gleichzeitig im Internet und in Foren gelesen. Und natürlich mit so Texten wie dem bereits erwähnten ASM86FAQ.TXT.
Jeder lernt es eben auch auf andere Weise.
Am besten lernt man programmieren(meiner Meinung nach), indem man einfach ein Programmprojekt anfängt, also irgendetwas mit einem Ziel programmiert (z.B. ein Spiel, eine Anwendung, ein Tool oder so). Auf diese Art setzt man sich gleich mit den entsprechend beim Programmieren anfallenden "Problemen" vertraut. Nur "programmieren lernen, damit man programmieren kann", bringt meist nicht ganz so viel - auch wegen des mangelnden Erfolgserlebnisses.
Aber - ohne Dich demotivieren zu wollen:
DEMO-Programmierer beschäftigen sich viel mit sehr theoretischen Dingen (und auch mit Mathematik) und wenden viele "Programmiertricks" an, um das zu tun, was sie tun. Solche Sachen eignet man sich erst mit der Zeit an - zuerst kommt die allgemeine Beherrschung von Assembler. Demo-Programmierung wird ja gemacht, um anderen (Computerfreaks) zu zeigen, "was man kann" - für Einzelpersonen ist das also eher die Königsdisziplin...

[freecrac]

oh ja, das sieht gut aus!
DANKE!

Es kann nicht Schaden beim lesen der Befehle diese in debug gleich einmal auszuprobieren.
Dann sieht man gleich was passiert.

Unter Windows98/XP öffnet man dafür einfach die Startleiste->Ausführen und tippt dort debug + enter ein.

-Vor der Eingabe-Zeile erscheint nun so ein Minus-Zeichen als prompt.
Mit a + enter kommt man in den Assemble-Mode. Dort erscheint nun vor jeder Zeile eine Adresse und dahinter wartet der Cursor auf unsere Assemblerbefehle die wir dort eintippen können.
Das sieht dann beispielsweise so aus:
1531:0100

Dort tippen wir mal ein Befehl ein + enter:
1531:0100 mov ax, 4321
1531:0103

Wenn der Befehl richtig getippt wurde, dann erscheint in der nächsten Zeile eine neue Adresse. Andernfalls kommt eine Fehlermeldung.
Wenn wir nichts eintippen + enter, dann verlassen wir den Assemblemode und das Minuszeichen als prompt erscheint wieder.

Nun können wir unser Befehl (mov ax, 432) ausprobieren.
Mit
g=cs:0100 0103
weisen wir debug an unseren Befehl zur Ausführung zu bringen und das bei der Adresse 0103 die Ausführung wieder beeendet werden soll.

Nachdem der Befehl ausgeführt wurde gibt debug die aktuellen Registerinhalte am Bildschirm aus.
Dort kann man an der ersten Stelle den Inhalt des AX-Registers =4321 sehen. Der Wert wurde somit erfolgreich in das AX-Regisster geschrieben.

Kombiniert man einige Befehle, dann wird es natürlich erst interessant. Werden es noch mehr Befehle, oder sind viele Verzweigungen(Sprungbefehle) vorhanden, dann wird es mit debug allerdings zu unübersichtlich.
Aber für "try and error" zum Ausprobieren der Befehle ist debug wie geschaffen und liefert schnelle Ergebnisse.

Debug Manual:
http://www.angelfire.com/electronic/tri ... /Debug.doc

...

Noch ein sehr anschauliches Doku:
https://www.fbi.h-da.de/fileadmin/perso ... -Teil2.pdf

Dirk

[freecrac]

Auf meiner Seite habe ich einen Text selbst verfaßt:
http://www.imperial-games.de/html/dosd2.htm
Der Text heißt "REAL MODE Beschreibung". Da werden schon einige Sachen dazu erwähnt.
Eine Liste der Befehle und auch einiges über Assembler steht in dem langen Text ASM86FAQ.TXT - ebenfalls auf besagter Seite zu finden. Dies ist aber weniger zum Lernen, sondern mehr als eine Art "Nachschlagewerk" gedacht.
Ich selbst habe hier ein Buch, das gar nicht mal so schlecht ist, wenn man mit Assembler anfangen will:
Es heißt "Maschinensprache für Einsteiger", geschrieben von Holger Schäkel.
Von Data Becker, ISBN 3-89011-303-6
(Einführung in die Assemblerprogrammierung von 8086 bis 80486.)
Hat damals 49 DM (ja, Westgeld!) gekostet.

Dises Buch habe ich auch gelesen und ich kann es ebenfalls empfehlen. (Es gibt auch viel Schund.)

Keine Ahnung, ob es das heute noch gibt, ich habe das schon sehr lange.
Ich persönlich fand es recht informativ. Aber ich habe mich dann später auch gleichzeitig im Internet und in Foren gelesen. Und natürlich mit so Texten wie dem bereits erwähnten ASM86FAQ.TXT.
Jeder lernt es eben auch auf andere Weise.
Am besten lernt man programmieren(meiner Meinung nach), indem man einfach ein Programmprojekt anfängt, also irgendetwas mit einem Ziel programmiert (z.B. ein Spiel, eine Anwendung, ein Tool oder so). Auf diese Art setzt man sich gleich mit den entsprechend beim Programmieren anfallenden "Problemen" vertraut. Nur "programmieren lernen, damit man programmieren kann", bringt meist nicht ganz so viel - auch wegen des mangelnden Erfolgserlebnisses.

Vollig richtig. (Ich dokumentieren es für mich auch noch am Rand der Routinen.)

Dirk

[drzeissler]

OK das ist eine spannende Sache.

Hier das definierte Angriffsziel: FLÜSSIGER RUCKELFREIER SCROLLER mit Text.

Maschine: 80286 (10Mhz) mit 80287 (8Mhz) und Diamond Speedstar Grafikkarte 1MB VGA

Doc

[Brueggi]

Ich würde nicht gleich am Anfang mit Debug oder einen "Monitor" arbeiten. Das ist zu umständlich (z. B. Sprünge). Ich selbst habe von Anfang an FASM (Flat Assembler, der ist Freeware) verwendet. Der läuft prima und erzeugt von COM- bis diverse EXE-Dateien alles.
Ich habe mir damals für 90 Mark ein Assemblerbuch gekauft. Das lag erstmal lange lange Zeit in der Ecke. Mein "Einstiegsprojekt" in x86-Asm ist quasi mein Betriebssystem. Wirkt auf den ersten Blick bescheuert, gleich mit sowas anzufangen, aber da ich schon viel Erfahrungen mit dem Z80 hatte, viel der Um- bzw. Aufstieg zum 286 nicht schwer. Lernbar ist es auf alle Fälle, man muss nur dranbleiben und nicht aufgeben.

[DOSferatu]

Ich habe auf dem PC noch nie ein "eigenständiges" ASM-Programm geschrieben.
Ich benutze immer Pascal als "Rahmen" und dann den in Pascal integrierten Assembler. (Ja, der geht nur bis maximal 286er. Alles, was 386er betrifft, mache ich mit direkten Bytes, die ich in den Code einfüge.) D.h. es ist immer nur max. 99% Assembler und drumherum Pascal - aber auch das Pascal wird ja compiliert. Meist programmiere ich es so "Hybrid" - d.h. manche Dinge in Pascal und zeitkritische Dinge (oder Dinge, die in ASM einfacher als in Pascal sind) dann in Assembler. (Meine GameSys2 ist z.B. in 100% Assembler programmiert und ist dann als function in Pascal aufzurufen.)
Ich finde diese Vorgehensweise irgendwie praktisch - so kann ich EXE Files (oder Units für Pascal) erzeugen, ohne mir selbst über die Header etc Gedanken machen zu müssen, da der "EXE-Rahmen" ja vom Pascal-Compiler erzeugt wird.
Natürlich kann man auf diese Weise kein eigenes Betriebssystem programmieren - aber daran hatte ich ohnehin nie wirklich Interesse. Einfach nur deshalb, weil ich nicht wüßte, was ich mit einem eigenen OS anfangen soll.

[freecrac]

Ich würde nicht gleich am Anfang mit Debug oder einen "Monitor" arbeiten. Das ist zu umständlich (z. B. Sprünge).

Stimmt, das Arbeiten gestaltet sich umständlich. Doch zum schnellen Ausprobieren einiger weniger Befehle eignet sich debug schon.

Ich selbst habe von Anfang an FASM (Flat Assembler, der ist Freeware) verwendet.

Ich hatte am Anfang so gut wie keine Unterlagen über die x86-CPU und auch kein Internet und ich kannte nur ganz wenige DOS-Befehle.
Vorher hatte ich auf dem C64 es kennengelernt wie man CPU-Register verwendet und damit auf Speicherbereiche zugreift.
Die Segmentierung des Speichers beim x86 habe ich erst einmal ignoriert, da mir die 64 KiB die man schon über ein 16 Bit Offsetregister adressieren kann mir riesig gross erschien.
So ist diese Menge an Speicher schon grösser als das was man maximal auf dem C64 zur Verfügung hat (, wenn ich mich nicht täusche waren es dort ca. 38 KiB).
Mit debug habe ich dann die ersten ersten Assembler-Befelhe ausprobiert. Danach habe ich MASM 5 kenengelernt. FASM habe ich noch nicht ausprobiert. Unter Linux habe ich NASM verwendet, der sich unter Debian leicht installieren läßt.

Der läuft prima und erzeugt von COM- bis diverse EXE-Dateien alles.

Vermutlich ist es nicht so schwer von einem Assembler zu einem anderen Assembler zu wechseln, wenn man die Unterschiede kennt.

Ich habe mir damals für 90 Mark ein Assemblerbuch gekauft. Das lag erstmal lange lange Zeit in der Ecke. Mein "Einstiegsprojekt" in x86-Asm ist quasi mein Betriebssystem. Wirkt auf den ersten Blick bescheuert, gleich mit sowas anzufangen, aber da ich schon viel Erfahrungen mit dem Z80 hatte, viel der Um- bzw. Aufstieg zum 286 nicht schwer.

Ein Z80 habe ich leider noch nie in die Finger bekommen.

Lernbar ist es auf alle Fälle, man muss nur dranbleiben und nicht aufgeben.

Die Lösung eines Problems beim Programmieren fällt mit oft im Bett vor dem Einschlafen ein, dann wenn man den Computer schon ausgeschaltet hat.
So bin ich dann auch schon einige Male wieder aufgestanden, um die Gedanken dann schnell auf ein Zettel zu schreiben, damit ich es nicht wieder vergesse, was ich mir da im Halbschlaf so ausgedacht habe.

Dirk