Assembler - Register dynamisch bestimmen.

[markus888]

Ich arbeite mich grade etwas in Assembler ein und schreibe meine ersten Codes damit.

Unter anderem frage ich mich, ob es irgendwie möglich ist, dynamischen Code zu generieren.

Die Aufgabe: In einem Multimedia Register muss ein Befehl auf eine dynamische Anzahl an Registern angewendet werden.

z.B. xmm0 bis xmm3 jeweils um 4 Bit shiften, dann xmm0 bis xmm3 jeweils mit xmm4 bis xmm7 summieren.

Das könnte dann genauso zmm0/ymm0 bis zmm(n) sein. - Ich weiß avx geht nicht direkt.

Zuerst dachte ich daran Opcodes dynamisch zu erzeugen um das ganze in einer Schleife zu durchlaufen.

DD EAX
DD EineVariable

aber das geht nicht - Fehlermeldung: Konstante erwartet.
Das einzige was der Compiler nicht reklamiert:
DD EineKonstante

mit DW/DB immer der Fehler (Konstante erwartet), egal wie ich die Konstante deklariere (Byte, Word, DWord)

In der Hilfe gibts ja diverse Beispiele dazu:

http://docwiki.embarcadero.com/RADSt...sembler-Syntax

z.B: DD MyVar { Pointer to MyVar }

Da wünscht sich der Compiler aber laut Fehlermeldung eine Konstante.

Kennt wer einen Weg, wie das funktionieren könnte, oder muss ich wirklich jeden Fall fix im Code hinterlegen?
Oder kann ich den Compiler dazu bewegen, eine normale Variable oder ein Register zu verwenden?

Danke Markus

[Neutral General]

DD wird zur Compilierzeit "ausgeführt" und setzt einfach nur einen festen Wert an diese Speicherstelle im Code.
Das geht natürlich nicht mit Variablen, weil die beim Compilieren natürlich noch undefiniert sind.
Da musst du mov benutzen um den Speicher an der Stelle zu modifizieren.
Bedenke aber dass Code Segmente standardmäßig readonly sind und nicht beschrieben werden können.
Da musst du wahrscheinlich noch vorher mit VirtualProtect dran.

[markus888]

Zitat:

Zitat von Neutral General (Beitrag 1462227)

Da musst du mov benutzen um den Speicher an der Stelle zu modifizieren.
Bedenke aber dass Code Segmente standardmäßig readonly sind und nicht beschrieben werden können.

Das wäre ja lustig, wenn es möglich wäre den Code so zu überschreiben.
Da müsste man wohl eher Hacker fragen. :-D

Zitat:

Zitat von Neutral General (Beitrag 1462227)

Da musst du wahrscheinlich noch vorher mit VirtualProtect dran.

Das habe ich nicht gekannt - bin ja ganz am Anfang was Delphi betrifft.
Hab bis jetzt nur einige dll und wenige Klassen für die Nutzung aus VBA geschrieben.
Würde mir jetzt aus meiner Sicht eher nichts bringen.
Notfalls muss eben jede Konstellation Coden.
Es geht mir vorerst darum die Grenzen der Möglichkeiten auszuloten.

Danke jedenfalls, für die Ideen.

[Neutral General]

Zitat:

Zitat von markus888 (Beitrag 1462238)

Zitat:

Zitat von Neutral General (Beitrag 1462227)

Da musst du mov benutzen um den Speicher an der Stelle zu modifizieren.
Bedenke aber dass Code Segmente standardmäßig readonly sind und nicht beschrieben werden können.

Das wäre ja lustig, wenn es möglich wäre den Code so zu überschreiben.
Da müsste man wohl eher Hacker fragen. :-D

Das ist definitiv möglich. Den Code zu überschreiben bzw. dynamisch zu erzeugen ist ja gerade das was du machen willst.
Und ja: das geht. Du musst halt wie gesagt nur den Speicher in dem du den Code schreiben/modifizieren willst mit VirtualProtect schreibbar machen.

VirtualProtect ist übrigens nicht Delphi-spezifisch. Das ist eine Windows API.
Also ja: das was du in deinem ursprünglichen Post fragst ist möglich.

[himitsu]

Danach mit VirtualProtect den Schreibschutz wiederherstellen und ein FlushInstructionCache kann auch nicht schaden, da hier ja Programmcode verändert wurde.

[markus888]

Zitat:

Zitat von Neutral General (Beitrag 1462250)

Also ja: das was du in deinem ursprünglichen Post fragst ist möglich.

Alles klar, dann werd ich mich mal einlesen.
Danke.

[TurboMagic]

Zitat:

Zitat von markus888 (Beitrag 1462238)

Zitat:

Zitat von Neutral General (Beitrag 1462227)

Da musst du mov benutzen um den Speicher an der Stelle zu modifizieren.
Bedenke aber dass Code Segmente standardmäßig readonly sind und nicht beschrieben werden können.

Das wäre ja lustig, wenn es möglich wäre den Code so zu überschreiben.
Da müsste man wohl eher Hacker fragen. :-D

Das gab es zumindest zu DOS Zeiten wirklich. Nannte sich selbstmodifizierender Code und wurde benutzt
um Virenscanner und Debugger auszutricksen. Debugger hatten scheinbar gerne Probleme, wenn man genau
den Befehl, den der Debugger gerade untersuchte genau zu dem Zeitpunkt modifiziert hat oder so
ähnlich... ;-)

Und wer Cracker die Debugger nutzten ärgern wollte baute viele Int3 Aufrufe ein. Soweit ich weiß
fungierte Int3 nämlich als Breakpoint... ;-)

[himitsu]

Zitat:

Zitat von TurboMagic (Beitrag 1462300)

Und wer Cracker die Debugger nutzten ärgern wollte baute viele Int3 Aufrufe ein. Soweit ich weiß
fungierte Int3 nämlich als Breakpoint... ;-)

Ist immernoch so und ist einer der wenigen Interupts, die man im Usermode jetzt noch benutzen kann, neben der passenden Winapi DebugBreak, welches intern auch gleich noch mit IsDebuggerPresent prüft.
z.B. als Inline-Assembler

Delphi-Quellcode:

asm int 3 end;

mittten im Delphi-Code (Win32). In Win64 so nicht mehr, da es dort kein Inline-Assembler gibt. (nur noch komplette Methoden)
Nur wenn kein Debugger dran hängt, dann raucht das natürlich mit einer Exception ab.

Und das FlushInstructionCache ist für modernere CPUs, welche den Befehlscode cachen, bzw. sich die nächsten Befehle schonmal vorab kopieren.

[markus888]

Zitat:

Zitat von himitsu (Beitrag 1462303)

Und das FlushInstructionCache ist für modernere CPUs, welche den Befehlscode cachen, bzw. sich die nächsten Befehle schonmal vorab kopieren.

Wenn ich die FlushInstructionCache brauche, ist das für mich schon eher wieder uninteressant.

Ich muss ja in jeder Schleife Code ändern.
Abgesehen davon, dass FlushInstructionCache mir dann noch zusätzlich die Inhalte von Registern ändern wird, was den gesamten Overhead dann noch vergrößert.
Da wird es wohl weit effizienter sein, ich verzichte auf den Luxus.

[himitsu]

Zitat:

muss ja in Schleife Code ändern

Da würde mir eher zu denken geben, ob da mit dem Konzept was nicht stimmen mag.

Zitat:

Da wird es wohl weit effizienter sein, ich verzichte auf den Luxus.

Dann heul aber auch nicht rum, wenn die CPU dann was anderes macht, als jetzt dort steht.