ASM zu binärcode bzw funktionierender exe?

[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