ASM-Tutorial
David Zotlöterer
wo findet ein C#-verwöhnter pseudocoder wie ich ein vernünftiges
(=auch für deppen verständliches) ASM-Tutorial?
LG, Dave
Jan Bruns
"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
Herbert Kleebauer
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.
David Zotlöterer
>Um ASM-Blöcke speziell in C Programmen zu verwenden?
Nö!
>(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?
>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!!
>Gruss
>Jan Bruns
LG, Dave
Jan Bruns
"David Zotlöterer":
>>(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
[INC BYTE PTR[EBX]]
> 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.
Ü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
"Stefan Reuther":
> Jan Bruns wrote:
> [INC BYTE PTR[EBX]]
>> 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.
> Ü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).
> 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?
Könen wir ja mal machen:
> 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
Jan Bruns <testzugan...@arcor.de> wrote:
> "Stefan Reuther":
[inc dword ptr [ebx] vs. incl (%ebx)]
>> Ü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?
> 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.
>> 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.
>> 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