Discussion:
ASM-Tutorial
(zu alt für eine Antwort)
David Zotlöterer
2006-07-18 12:28:48 UTC
Permalink
Hi NG,

wo findet ein C#-verwöhnter pseudocoder wie ich ein vernünftiges
(=auch für deppen verständliches) ASM-Tutorial?

LG, Dave
Jan Bruns
2006-07-18 18:21:32 UTC
Permalink
Post by David Zotlöterer
wo findet ein C#-verwöhnter pseudocoder wie ich ein vernünftiges
(=auch für deppen verständliches) ASM-Tutorial?
Also ich bin für die Verwaltung von Links irgendwie völlig "unzuständig".

Käme wohl erst mal drauf an, wozu Du ein ASM-Tutorial suchst.

Um ASM-Blöcke speziell in C Programmen zu verwenden? Dann
würde sich vielleicht eher ein Tutuorial in gas-Syntax eignen,
obwohl ansonsten (zumal unter Windows...) eigentlich die
intel-Syntax für x86-CPUs gebräuchlicher ist. Dabei geht
es zwar nur um Schreibweise, aber dieser eine Assembler
(nämlich das Tool gnu as, welches bspw. von Hochsprachcompilern
verwendet wird) verwendet nunmal eine etwas eigenartige
Schreibweise, die für so komplexe "instruction sets", wie
sie die x86-Familie bietet, eher ungeeignet ist.

Zielplattform 16,32 oder 64 Bit? Von der Beschäftigung mit
uraltem 16-Bit Kram kann ich so erstmal nur abraten, verwirrt nur
unnötig, für den Anfang. Programmieren für 64 Bit setzt natürlich
eine entsprechende CPU und entsprechendes Betriebsysystem voraus.

Gruss

Jan Bruns
David Zotlöterer
2006-07-19 06:28:06 UTC
Permalink
Post by Jan Bruns
Käme wohl erst mal drauf an, wozu Du ein ASM-Tutorial suchst.
Ja ne - is klar... sry
Post by Jan Bruns
Um ASM-Blöcke speziell in C Programmen zu verwenden?
Nö!
Post by Jan Bruns
(nämlich das Tool gnu as, welches bspw. von Hochsprachcompilern
verwendet wird) verwendet nunmal eine etwas eigenartige
Schreibweise, die für so komplexe "instruction sets", wie
sie die x86-Familie bietet, eher ungeeignet ist.
Hä? Deutsch?
Post by Jan Bruns
Zielplattform 16,32 oder 64 Bit? Von der Beschäftigung mit
uraltem 16-Bit Kram kann ich so erstmal nur abraten, verwirrt nur
unnötig, für den Anfang. Programmieren für 64 Bit setzt natürlich
eine entsprechende CPU und entsprechendes Betriebsysystem voraus.
Eindeutig 32!!
Post by Jan Bruns
Gruss
Jan Bruns
LG, Dave
Jan Bruns
2006-07-19 16:08:08 UTC
Permalink
Post by David Zotlöterer
Post by Jan Bruns
(nämlich das Tool gnu as, welches bspw. von Hochsprachcompilern
verwendet wird) verwendet nunmal eine etwas eigenartige
Schreibweise, die für so komplexe "instruction sets", wie
sie die x86-Familie bietet, eher ungeeignet ist.
Hä? Deutsch?
Naja, oft schreibt man bspw. sowas:

INC BYTE PTR[EBX]

INC WORD PTR[EBX]

INC DWORD PTR[EBX]

"EBX" ist ein Register der CPU, "INC" ein beo intel nachzulesender Befehl
der CPU. das Sclüsselwort "PTR" deutet, genau wie die eckigen Klammern
einen Speicherzugriff an. Je nach verwendetem Assembler kann man entweder
das "PTR" oder die eckigen Klammern, oder manchmal sogar beides weglassen.

In der gas-Syntax säehen die Befehle ungefähr so aus:

incb (%ebx)
incw (%ebx)
incl (%ebx)


Oder so ähnlich, jedenfalls mit Operandengrössensuffix am Befehl,
was natürlich nicht so toll ist, wenn man, wie bei der x86-Familie
sehr viele Befehle hat, die sich teils auch nur durch einen Buchstaben
(und ihre Funktonalität) unterscheiden.

Gruss

Jan Bruns
Stefan Reuther
2006-07-19 16:41:52 UTC
Permalink
Jan Bruns wrote:
[INC BYTE PTR[EBX]]
Post by Jan Bruns
incb (%ebx)
incw (%ebx)
incl (%ebx)
Oder so ähnlich, jedenfalls mit Operandengrössensuffix am Befehl,
was natürlich nicht so toll ist, wenn man, wie bei der x86-Familie
sehr viele Befehle hat, die sich teils auch nur durch einen Buchstaben
(und ihre Funktonalität) unterscheiden.
Über Geschmack kann man nicht streiten, aber das ist ja nun wirklich
kein Grund. Die gas-Befehle sind sogar kürzer! Konsequenterweise
müsstest du nach deiner Argumentation dann auch
movs byte ptr es:[di], byte ptr ds:[si]
statt
movsb
schreiben.

Ich finde die gas-Syntax eigentlich recht umgänglich. Ist halt
Gewöhnungssache. Wirklich nervig finde ich, dass man
movl foo(,%ebx,2), %eax
nicht auf Anhieb ansieht, was es bedeutet.
mov eax, [foo + 2*ebx]
ist da etwas aussagekräftiger.

Aber die Operandensuffixe kannst du bei den meisten Befehlen inzwischen
weglassen. 'add %eax,foo' ist immer eine 32-bit-Addition, weil mit %eax
nix anderes geht.


Stefan
Jan Bruns
2006-07-20 06:40:14 UTC
Permalink
Post by Stefan Reuther
[INC BYTE PTR[EBX]]
Post by Jan Bruns
incb (%ebx)
incw (%ebx)
incl (%ebx)
Oder so ähnlich, jedenfalls mit Operandengrössensuffix am Befehl,
was natürlich nicht so toll ist, wenn man, wie bei der x86-Familie
sehr viele Befehle hat, die sich teils auch nur durch einen Buchstaben
(und ihre Funktonalität) unterscheiden.
Über Geschmack kann man nicht streiten, aber das ist ja nun wirklich
kein Grund. Die gas-Befehle sind sogar kürzer!
Ja, das ist doch das verwirrende daran. Der x86-Befehlssatz umfasst weit
über 100 (wenn nicht gar mehrere 100) Befehle, deren Namen vielleicht im
Schnitt 5 Zeichen lang sind.
Zudem gibt es sogar Befehlsnamen, die andere Befehlsnamen komplett am
Anfang enthalten, wie bspw. "IN" in "INC".

Das sind ziemlich andere Verhältnisse, im Vergleich zu den anderen CPUs,
die gas traditionell unterstützt (vornehmlich 8-Bit CPUs mit je vielleicht
50 Befehlen).
Post by Stefan Reuther
Konsequenterweise
müsstest du nach deiner Argumentation dann auch
movs byte ptr es:[di], byte ptr ds:[si]
statt
movsb
schreiben.
Wieso das denn? Kann MOVS denn noch was anders?

Habe ich mit dem Ausschreiben impliziter Details argumentiert?
Post by Stefan Reuther
Ich finde die gas-Syntax eigentlich recht umgänglich.
Naja, ich weiß nicht.
Braucht man -selbst bei einem Crossassembler- wirklich ein Steuerzeichen,
um Registernamen zu kennzeichnen? Hätte man das nicht besser für
Speicherreferenzen, die zufällig einen Registrernamen tragen, verwenden
können? Doch, hätte man.


Gruss

Jan Bruns
Stefan Reuther
2006-07-21 22:02:53 UTC
Permalink
Hallo,
[inc dword ptr [ebx] vs. incl (%ebx)]
Post by Jan Bruns
Post by Stefan Reuther
Über Geschmack kann man nicht streiten, aber das ist ja nun wirklich
kein Grund. Die gas-Befehle sind sogar kürzer!
Ja, das ist doch das verwirrende daran. Der x86-Befehlssatz umfasst weit
über 100 (wenn nicht gar mehrere 100) Befehle, deren Namen vielleicht im
Schnitt 5 Zeichen lang sind.
Zudem gibt es sogar Befehlsnamen, die andere Befehlsnamen komplett am
Anfang enthalten, wie bspw. "IN" in "INC".
Und?
Post by Jan Bruns
Das sind ziemlich andere Verhältnisse, im Vergleich zu den anderen CPUs,
die gas traditionell unterstützt (vornehmlich 8-Bit CPUs mit je vielleicht
50 Befehlen).
gas? 8-bit-CPUs? Meiner erzählt ja was von Alpha, ARM, M68k, MIPS,
PowerPC, SPARC.

Ansonsten sei froh, dass es überhaupt Mnemonics gibt :-) Auf dem
Prozessor, den ich gerade malträtiere, heißt der Additionsbefehl
r1 = r1 + r2;
und die Addition mit Saturierung
r1 = r1 + r2 (s);
Nicht zu verwechseln mit der halbwortweisen Addition ("Vektor-
Addition")
r1 = r1 + r2 (v);
Sowas schlägt sich echt bekloppt im Handbuch nach.
Post by Jan Bruns
Post by Stefan Reuther
Konsequenterweise
müsstest du nach deiner Argumentation dann auch
movs byte ptr es:[di], byte ptr ds:[si]
statt
movsb
schreiben.
Wieso das denn? Kann MOVS denn noch was anders?
Zum Beispiel
movs byte ptr es:[di], byte ptr gs:[si]
oder
movs byte ptr es:[edi], byte ptr ds:[esi]
Ersterer geht (meines Wissens nicht in allen Assemblern) mit
'seggs movsb', letzterer eigentlich nur mit 'db 67h' davor.
Post by Jan Bruns
Post by Stefan Reuther
Ich finde die gas-Syntax eigentlich recht umgänglich.
Naja, ich weiß nicht.
Braucht man -selbst bei einem Crossassembler- wirklich ein Steuerzeichen,
um Registernamen zu kennzeichnen? Hätte man das nicht besser für
Speicherreferenzen, die zufällig einen Registrernamen tragen, verwenden
können? Doch, hätte man.
Musste man bei der Intel-Syntax zur Speicherreferenzierung unbedingt
die eckigen Klammern nehmen, die auf deutschen Tastaturen schwer
eingebbar sind? Hätten es nicht auch runde Klammern sein können?
Warum ist Intel-Syntax die einzige mir bekannte Assemblersyntax, in
der ein indirekter Sprung 'jmp bx' und nicht 'jmp (bx)' codiert
wird? Warum setzt man bei 'in al,dx' die Quelladresse nicht in
Klammern, bei 'mov al,[bx]' aber schon? Warum frisst TASM den Befehl
'jmp 0FFFFh:0' nicht?

Hier kann man sicherlich stundenlang weitere Beispiele anführen. Es
bringt nur nix. 'gas' ist halt anders. Nicht "eigenartig" oder
"schwer", nur "anders". Jemand der von M68k oder SPARC kommt, wird
sich wie zu Hause fühlen (von ersterem hat AT&T diese Syntax dann
vermutlich auch geerbt). Klar ist es nervig, dass es zwei Dialekte
gibt. Aber die sind beide verbreitet genug, dass wir keinen von
beiden totkriegen werden.

Allerdings kann zumindest gcc inzwischen auch etwas, das fast wie
Intel-Syntax aussieht, generieren, und der gas kann das auch lesen.


Stefan

Herbert Kleebauer
2006-07-18 20:02:07 UTC
Permalink
Post by David Zotlöterer
Hi NG,
wo findet ein C#-verwöhnter pseudocoder wie ich ein vernünftiges
(=auch für deppen verständliches) ASM-Tutorial?
Als erstes mußt du dich für einen Assembler entscheiden, dann
kannst du nach einem dazu passenden Tutorial oder Buch suchen.
Auf alle Fälle solltest du dir die Prozessorhandbücher von
Intel's Webserver herunterladen (fang mit den alten P2
Manuals an, die sind noch nicht so umfangreich).

Zu den meisten Assemblern existieren auch eigene Diskussionsforen,
ansonsten sind die Gruppen alt.lang.asm und comp.lang.asm.x86
zu empfehlen.
Loading...