ASM zu binärcode bzw funktionierender exe?

[Memnarch]

Tag allerseits.
Da mich das gebiet Assembler total interressiert(sowie Compilerbau :twisted:), würde ich gerne wissen, wie man von Assembler code zu einem ausführbaren programm kommt.

Wenn ich es richtig verstanden habe ist es doch so verkettet:

Hochsprache -> Assembler -> Binärcode (bitte dringenst korrigieren wenn ich falsch liege)


MFG
Memnarch

[generic]

Assembler = Binärcode

Assembler ist nur eine Textanzeige des Binärcodes.
Das kannst du vergleichen mit der Darstellung von Zahlen, diese lassen sich im dezimalen System besser lesen als im binären.

0011 = 3

Es gibt nun noch spezielle Editoren, welche ASM-Code als "Hochsprache" behandeln und Sprungmarken mit Text darstellen. Diese Textmarken werden dann in Adressen beim kompilieren umgesetzt. Ohne diese Editoren müsste man die Adresse ausrechnen und eingeben.

Wenn du mal CPU "anfassen" möchtest, dann empfehle ich dir einen Mikrocontroller zu nehmen und diesen zu programmieren.

Beliebt sind die Atmel 8Bit Risc Prozessoren - billig und leicht zu beschalten.
Das schöne da dran - man muss alles per Hand machen, da es kein OS gibt.

[p80286]

Die einfache Antwort wäre
Compilieren,Linken,fertig.
Aber das willst Du wahrscheinlich nicht lesen. Es gibt "Sprachpakete" bei denen es so gemacht wird, wie Du es skizziert hast:
Hochsprache -> (Makro)Assembler -> Binärcode -> Ausführbares Programm

Was sind denn Deine konkreten Anliegen?

Gruß
K-H

[Memnarch]

Ich glaube wir haben uns etwas verpasst^^.

mir geht es darum:

wen ich z.B den ausgeschriebenen befehl "mov" habe, wie wird der "übersetzt". Gibt es dafür eine tabelle, wird der wert einfach aus den Asciizeichen berechnet? mit "mov" im Klartext kann eine CPU ja schlecht was anfangen o.O.

Und dan ebend noch: wie ist das mit einer Executable unter windows.?

EDIT: rote box war wohl wieder auf urlaub....

EDIT2: Also: ich möchte ein programm schreiben dass aus einer art selbst definierter hochsprache(hoch in anführungszeichen...eher was sehr simples proceduales) den noch für menschenlesbaren ASM code generiert. Ok da bin ich noch im stande mir selbst zu helfen. Wenn ich aber bei dem lesbaren ASM angekommen wäre, wie geht es dan weiter? Was muss ich tun, damit ich daraus dan ein ausführbares programm machen kann?

MFG
Memnarch

[Neutral General]

Ich glaube ihr verwirrt ihn nur mehr...

Also man kann Assembler quasi 1:1 in Binären Code (ich nenne es mal so) umwandeln.

z.B. entspricht der Befehl "hlt" dem Byte (Opcode) 0xF4

mov eax, 20
inc eax
hlt

:arrow:

B8 14 00 00 00
40
F4

Liste mit Befehlen/Opcodes: http://ref.x86asm.net/

Infos zum Aufbau von Exe-Dateien findest du bei Wikipedia:
http://de.wikipedia.org/wiki/Portable_Executable
und natürlich bei Microsoft selbst:
http://msdn.microsoft.com/en-us/wind...dware/gg463119

[Bummi]

Meinst Du TASM oder MSAM?

[Memnarch]

@Neutral General: ah das ist doch schonmal was. Aber "quasi" bedeutet ja das ich trotzdem irgendwo ne referenz haben muss(also welcher opcode für welchen befehl ;) ). Aber damit komm ich schonmal weiter, danke.


@Bummi: o.O?

[BUG]

Das Intel Architectures Software Developer's Manual ist das was du suchst, wenn du Bytecode selbst erstellen willst (ein Tutorial ist das allerdings nicht).
Kapitel 2 sollte imho die Zusammensetzung der Instruktionen beschreiben.

[p80286]

@Bummi
ich denke das ist in diesem zusammenhang egal

Gruß
K-H

Edith:
vielleicht noch als Zusatz, der "Assemblercode" für ein LINUX-Programm ist der gleichen wie bei windows, da der Processor der gleiche ist. Nur die systemspezifischen Befehle, unterscheiden sich. (Linker)
Also alles was Du für das Laden des Programms und für die Speicheradressierung brauchst.
(OK ein bischen API und ....)

[Namenloser]

Zitat:

Zitat von Memnarch (Beitrag 1114008)

@Neutral General: ah das ist doch schonmal was. Aber "quasi" bedeutet ja das ich trotzdem irgendwo ne referenz haben muss(also welcher opcode für welchen befehl ;) ). Aber damit komm ich schonmal weiter, danke.

Es gibt auf der Seite verschiedene Referenzen, ich habe für meinen Brainfuck-JIT-Compiler diese verwendet: http://ref.x86asm.net/coder32.html

[himitsu]

Besonders blöde ist es ja, daß die Delphi-IDE quasi einen Binär-zu-ASM-Decoder integriert hat. (siehe CPU-Ansicht)

Würde BorCodeGero solche internen Sachen uch mal "öffentlich" zur Verfügung stellen, dann hätten sie gleich mal ganz "schöne" Komponenten/Codes im Delphi integriert, wofür man jetzt noch externe Bibliotheken nutzen muß. (obwohl eigentlich etwas vorhanden ist)

Und wenn diese ASM-Deklarationen in einer ordentlichen Weise veröffentlich wären, dann könnte man sie bestimmt auch ganz gut für den umgekehrten Weg (ASM-zu-Binär) nutzen.

Genauso schön wäre es schön, wenn der Codeparser (der vorm Compiler) öffentlich wäre, dann hätte man einen aktuellen Parser, welcher wirklich mal die aktuellen Delphicodes parsen könnte.
(gut für sehr kleine Script-Engines)

[Namenloser]

So gesehen könnte Embarcadero auch gleich noch den Source-Code des Compilers und der IDE dazupacken :stupid:

Zitat:

Zitat von himitsu (Beitrag 1114028)

Genauso schön wäre es schön, wenn der Codeparser (der vorm Compiler) öffentlich wäre, dann hätte man einen aktuellen Parser, welcher wirklich mal die aktuellen Delphicodes parsen könnte.
(gut für sehr kleine Script-Engines)

Anscheinend schaffen die das ja selbst nicht (siehe Error Insight).

[himitsu]

Beim Error-Insight hab ich eher den Verdacht, als wenn da ein anderer Parser genutzt wird, als für den Compiler.
Mit dem selben Parser und einem Background-Compiler (ohne aktive Codeoptimierungen und Co.) könnte man man da bestimmt etwas zusammenbekommen, welches besser läuft. :stupid:



Nee, nicht den ganzen Compiler, nur etwas, was den Quellcode einließt und erstmal in eine Art DOM-Objekt zerlegt.
Darüber könnte man auch endlich mal einen Multi-Pass-Compiler bauen (denn der aktuelle Single-Pass-Compiler mag vielleicht schneller sein, hat aber auch gewaltige Nachteile).

Wo man jetzt doch sowieso mehrere Compiler hat,
macht es sich eh besser, den Quellcode erstmal zu zerlegen, darin vielleicht noch ein paar optimierungen vorzunehmen und kann es dann an den entsprechenden Compiler weitergeben, der ja nun selber keinen Code mehr parsen muß (da alles schon geparst und syntaktisch kontrolliert vorliegt) und somit sich nur noch auf seine wesentliche Aufgabe konzentrieren zu braucht.
Für's Code-Insight und das Error-Insight kann man sich dann aus ganz einfach das Wichtigste rausziehen, aus den den vorgeparsten Daten.

Da sich die Syntax ständig verändert/erweitert hätte man dann einen Parser, welcher auch wirklich mit allen Codes klar kommt, da er auch von denen kommt, welche die Syntax festgelegt haben.


Die letzen Delphi-Parser stammen doch quasi noch aus Delphi 7-Zeiten und danach gibt es kaum noch etwas, was wirklich mit all den neueren Feinheiten von Generics, Operatoren, recordmethoden, Klassenvariablen oder alternativen recordstrukturen klarkommt.
Neueres ist doch mehr nur für einen begrenzten Wortschatz, von dazugehörigen "kleinen" Scriptengines, erstellt wurden.

[Memnarch]

Zitat:

Zitat von NamenLozer (Beitrag 1114025)

Es gibt auf der Seite verschiedene Referenzen, ich habe für meinen Brainfuck-JIT-Compiler diese verwendet: http://ref.x86asm.net/coder32.html

Herje ist das ein wust^^.

Schätze mal das aber zuersteinmal die implementierung der 1Byte opcodes reichen würde oder?

Mal abgesehen davon rätsel ich gerade an einigen stellen der tabelle rum.

Spalte "PO" ist klar, das ist der primary opcode, mnemonic der befehl als geschriebener Text, so und jetzt hänge ich bei den spalten op1, op2, op3, op4.
op = operand? Da bräuchte ich mal kurz nen anstubs. ich kenne nur

befehl a, b

wieso den jetzt bis op4?

und wenn ich das richtig sehe dient 0F dazu einen 2bytebefehl(0F als erstes byte) zu markieren?

MFG
Memnarch

[Namenloser]

Ja, opN steht für den N-ten Operanden. Ein Operand ist meistens entweder

• ein Register (z.B. eAX, AL usw.)
• eine direkt (=immediate) auf den OP-Code folgende Konstante im Code (imm8, imm16, imm32)
• ein mod-R/M-Byte – eine auf konfuse Weise kodierte Kombination aus einem Register (r) und einer Adresse (m wie Memory) (in der Tabelle gekennzeichnet durch
  Delphi-Quellcode:

  r/m8

  ,
  Delphi-Quellcode:

  r16/32

  ,
  Delphi-Quellcode:

  r/m16/32

  etc.)

Die Sache mit dem mod-R/M-Byte zu verstehen, hat mich damals am meisten Zeit gekostet. Eine wirkliche Erklärung habe ich dazu nicht gefunden, aber immerhin diese Übersicht¹, und daraus habe ich es mir dann zusammengereimt. Oben steht das Ziel der Operation (immer Register), links die Quelle (Register, oder Adresse).

Wenn z.B. im Register

Delphi-Quellcode:

EBX

eine Speicher-Adresse steht, und du den an dieser Adresse stehenden Wert in das Register

Delphi-Quellcode:

EAX

kopieren willst (als Mnemonic:

Delphi-Quellcode:

MOV EAX, [EBX]

²), so lautet der OP-Code dafür:

Delphi-Quellcode:

89 03

. Das erste Byte ist die Instruction

Delphi-Quellcode:

MOV

, das zweite Byte ist das mod-R/M-Byte für „EAX ← [EBX]“ (siehe Tabelle).

Delphi-Quellcode:

MOV EAX, EBX

(ohne eckige Klammern (!), also direkte Kopie des Register-Inhaltes) wäre hingegen

Delphi-Quellcode:

89 C3

.

¹ gerade jetzt sehe ich, dass das gleiche auch unten auf der anderen Seite steht...
² die eckigen Klammern sind bekanntlich der Dereferenzierungs-Operator, das Assembler-Äquivalent zu

Delphi-Quellcode:

Wert^

in Delphi

[Memnarch]

Ih hatte es dann bisher so verstanden:

Befehl + Ziel(Register) = OpCode

deswegen ist

MOV EAX, X ein anderer OpCode als MOV EBX, X

EDIT: ah ne wohl doch was falsch verstanden^^

aber das mit dem Modbytes...dein link führt mich auf die hauptseite o.O

EDIt2: ah hab die tabelle gerade am ende der OpCode seite gefunden :P

EDIT3: ah ja jetzt hats klick gemacht bei der tabelle. Deswegen gibt es auch z.B für ADD verschiedene opcodes, weil das wiederum abhängig davon ist, welche zulässigne register kombinationen mit dem befehl auftreten können. Mh es klingelt im kopf immer lauter :stupid:

[Memnarch]

SO nochmal eine Frage zu der tabelle:

bei den Op1-4 stehen dadrunter die zulässigen register bzw memoryblöcke.

Wenn dort nur "r" ohne r8, r16 etc steht, beinhaltet das alle register die in der ModR/M Byte tabellen ein (\r) hinter sich haben?

und mm steht für eine adresse zu einem speicherblock, richtig? wie wird die denn dann angegeben, also an den opcode angehängt?


MFG
Memnarch

[Neutral General]

mm steht laut der letzten Tabelle auf der Seite für die Register MM0 bis MM7.

Speicheradressen bzw. Konstanten werden wie in meinem Beispiel drangehangen:

mov eax, 20

=>

B8 14 00 00 00

Es sei denn ich habe dich falsch verstanden...

[Memnarch]

Mh, seh ich das ichtig dass die operanden umgekehrt werden?

mov eax, 20

=>

mov 20, eax//das bedeutet doch dein bytecode? und dein Hexwert wird von links nach recht und nicht von rechts nach links gelesen?

in der ModByte tabelle steht für 00 aber [eax] und nicht eax. Wieso den dereferenzierten?

und wie wird hier unterschieden sodass erkannt wird, dass nach dem opcode für mov das eine eine adresse und keine eventuelle nezeichnung für ein anderes mrmodbyte ist?

Dazu bräuchte ich mal eine detaliertere erläuterung

[Neutral General]

Nein,

B8 bedeutet: mov eax, <32-Bit Wert>
darauf folgt der entsprechende 32-Bit Wert (Little Endian):

Code:

   Hex       32-Bit              Little Endian
20 ===> 0x14 =====> 0x00000014 ============> 14 00 00 00

:arrow:

B8 14 00 00 00

[Memnarch]

AH, gerade diese seite gefunden:
http://www.posix.nl/linuxassembly/na.../nasmdoca.html

da steht genau erklärt wie opcodes notiert werden (z.B das +r).

Damit kapier ich auch wieso du da nur den opcode direkt gefolgt von dem hexwert hast. :)

MFG
Memnarch

[Neutral General]

kannst auch mal in Delphi nen asm-Block benutzen, ein paar Anweisungen reinschreiben, dann nen Breakpoint auf die 1. Anweisung und wenn der Debugger angehalten hat ins CPU-Fenster gucken (Strg+Alt+C). Da steht sowohl der Assemblerbefehl als auch der Bytecode des Befehls drin.

[Memnarch]

Hab icha cuh schon beutzt. war gut um mal rauszufinden ob ich vorgehensweise X richtig verstanden habe :).

werde ich auch zum gegentesten nutzen. wenn ich wirklich mal nen programm hab das bytecode ausschmeißt, werd ich daneben den selben asm code auchnochmal in delphi angucken und vergleichen :)

edit: strg+alt+c geht aber nichtmehr sobald Smartinspect drin ist >.<


MFG
Memnarch

[himitsu]

Zitat:

Zitat von Memnarch (Beitrag 1114143)

edit: strg+alt+c geht aber nichtmehr sobald Smartinspect drin ist >.<

Im Notfall kann man auch noch über das Menü gehen, wofür Strg+Alt+C die Schnellwahl/Shortcut ist. :zwinker:

[Namenloser]

Zitat:

Zitat von Memnarch (Beitrag 1114061)

aber das mit dem Modbytes...dein link führt mich auf die hauptseite o.O

Sry, fix’d.

Zitat:

Zitat von Neutral General (Beitrag 1114089)

mm steht laut der letzten Tabelle auf der Seite für die Register MM0 bis MM7.

Speicheradressen bzw. Konstanten werden wie in meinem Beispiel drangehangen:

mov eax, 20

=>

B8 14 00 00 00

Es sei denn ich habe dich falsch verstanden...

Ich versteh nicht ganz, was du uns mit diesem Beitrag sagen willst oO Was du sagst, ist ja richtig, aber wo ging es denn um MMX-Register?