![]() |
Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo Gemeinde!
Folgende Methode bereitet mir leichte Bauchschmerzen:
Delphi-Quellcode:
Ich bekomme keinen direkten Zugriff auf die privaten Variablen des Objektes FMask über den Punktoperator. Die Anweisung [eax].FMask.FWidth wird vom Compiler nicht korrekt aufgelöst. So bleibt mir nur der Umweg über mov ebx, [eax].FMask den Zeiger auf das Objekt zu ziehen und den Offset zu FWidth direkt über [ebx+$04] zu setzen. Hab auch schon diverse Casting Varianten ausprobiert; leider ohne Erfolg. Vielleicht gibt es doch eine Lösung, denn so ist der GAU vorprogrammiert, wenn ich die privaten Variablen der Klasse TDIBMask ändere.
Function TDIBSection24.GetMaskValue(X,Y:DWord):Byte;
asm // eax = Self; edx = X; ecx = Y push ebx cmp [eax].FMask, 0 je @NoMaskValue // Keine Maske definiert // X-Wert anpassen und überprüfen mov ebx, [eax].FMaskRect.Left sub edx, ebx // X-Offset der Maske berücksichtigen js @NoMaskValue // X < 0 -> ausserhalb der Maske mov ebx, [eax].FMask // Zeiger auf FMask Object cmp edx, [ebx+$08] // ebx + $08 = FMask.FWidth jge @NoMaskValue // X >= Width -> ausserhalb der Maske add edx, [ebx+$04] // Zeiger auf Byte X, 0 // Y-Wert überprüfen und anpassen mov edi, [eax].FMaskRect.Top sub ecx, edi // Y-Offset der Maske berücksichtigen js @NoMaskValue // Y < 0 -> ausserhalb der Maske cmp ecx, [ebx+$0C] // X >= FMask.FHeight -> ausserhalb der Maske jge @NoMaskValue jecxz @FirstRow imul ecx, [ebx+$08] // Y-Offset nur bei Y > 0 add edx, ecx @FirstRow: mov eax, [edx] and eax, $000000FF jmp @EndFunc @NoMaskValue: xor eax, eax // Result = 0 @EndFunc: pop ebx End; Vielen Dank für´s mitdenken. Gruss OLLI |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo OLLI,
probier diesen Cast:
Delphi-Quellcode:
type
TMyClass = class FAttribute : Integer; end; TAnotherClass = class private FAggregate : TMyClass; end; //... asm mov eax, TAnotherClass([ebx]).FAggregate.FAttribute end; |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo Choose!
So wie ich Deinen Code interpretiere gehört Deine asm-Funktion zur Klasse TAnotherClass. Dann ist der Cast aber doch unnötig. [ebx].FAggregate liefert den Zeiger auf das Objekt FAggregate. Genauso hab ich es doch probiert und bekomme vom Compiler einen völlig falschen Offset berechnet. Oder hab ich was falsch verstanden? Gruss OLLI |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Nachtrag!
Mir erschien diese Variante noch plausibel: mov eax, TMyClass([ebx].FAggregate).FAttribute Dem Compiler leider nicht :? |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo OLLI
Zitat:
Leider habe ich meinen Betrag etwas zu flüchtig abgegeben, er wird zwar kompiliert, allerdings zu Code, wie man ihn warhscheinlich nicht erwartet. Wenn ich Dich richtig Verstanden habe, möchtest Du etwas in der Form
Delphi-Quellcode:
haben, oder?asm //Result:= MyObject.FMyStyle.FMyFont.FMyColor mov eax, TMyClass([ebx]).FMyStyle.FMyFont.FMyColor end Dieser Source lässt sich leider nicht innerhalb eines Statements derefferenzieren und würde auch vom Delphi-Compiler in mehrere Statements übersetzt werden. Sollte es sich bei einem Attribute allerdings um einen Record handeln, lässt sich der Zugriff über ein Displacement erreichen und Delphi übersetzt es korrekt:
Delphi-Quellcode:
Ich habe den Fall mit Deinem D5-Enterprise als auch mit D7-Architect getestet. Leider gibt der Compiler im Fall eines aggregierten Objekts weder eine Warnung noch einen Fehler aus.
TMyClass = class
FAttribute : TPoint; end; var myObject: TMyClass; begin myObject:= TMyClass.Create; myObject.FAttribute.x:= 42; myObject.FAttribute.y:= 23; asm mov ebx, myObject mov ecx, TMyClass([ebx]).FAttribute.y end; |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo,
ich hab' zwar nur wenig Plan von Assembler, aber ich frage mich ernsthaft: Warum? Private Felder sind nun mal privat und wenn ihr über Trick 17 versucht direkt darauf zuzugreifen, macht ihr damit das ganze Konzept von OOP & Kapselung zu nichte :wall: Ihr solltet lieber darüber nachdenken ob das wirklich nötig ist und ob es nicht einen einfacherern Weg gibt. |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo Choose!
Erst mal vielen Dank für Deine ausführliche Nachricht! 8) Das mit den Record-Typen ist klar. Hab ich ja auch in meinem Code verwendet (TRect). Ich erwarte auch gar nicht, dass der Compiler das Statement innerhalb eines Befehls dereferenzieren kann. Aber ich möchte wenn nur irgend möglich Befehle wie: [ebx+$04] vermeiden. Da sind Fehler im warsten Sinne des Wortes vorprogrammiert. Es muss doch einen Weg geben, dem Compiler begreiflich zu machen, dass im Register ebx nicht der Zeiger auf das Objekt Self sondern eben ein anderes Objekt steht. :gruebel: OLLI |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo mr2!
Hier geht es nicht um Trick 17 sondern um Perfomance. OOP find ich geil sonst würde ich nicht für meine NONVCL Anwendungen konsequent (fast) alles in Klassen kapseln. Die beschriebene Methode ist privat deklariert und kann von aussen nicht aufgerufen werden. Beide Klassen sind in derselben Unit von mir deklariert. Und ob ich nun über property Width:DWord read FWidth ... oder direkt auf FWidth zugreife ist doch wohl Jacke wie Hose oder? Gruss OLLI |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Zitat:
wenn ich OLLI richtig verstehe, ist das nicht das eigentliche Problem: Private Felder sind außerhalb des Scopes auch in ASM nicht sichtbar. Vielmehr scheint er einen performaten Zugriff aus einer Hilfsklasse heraus erreich zu wollen (dies hätte man in C++ mit Friends, in Java mit protected und Packages und in Delphi eben über das selbe PAS-File erreicht). Darüber hinaus sind solche "17er Tricks", die Du zu meinen scheinst, auch mit purem ObjectPascal hinzubekommen... [Edit]Inzwischen (ich hab mal wieder zulange getippt) hat OLLI das ja bestätigt ;)[/EDIT] Zitat:
das sollte so Funktionieren (nur mit D7 getestet):
Delphi-Quellcode:
in eax landet, wir erwartet, 0x2a.
type
TMyClass = class private FAttribute : Integer; public constructor Create(AValue: Integer); end; constructor TMyClass.Create(AValue: Integer); begin inherited Create; FAttribute:= AValue; end; procedure TForm1.Button1Click(Sender: TObject); var myObject: TMyClass; myInt: Integer; begin myObject:= TMyClass.Create(42); try asm mov ebx, myObject mov eax, TMyClass([ebx]).FAttribute end finally myObject.Free; end; end; Vielleicht kannst Du einmal eine Zuweisung in der Delphi Language schreiben, die Du gerne 1:1 in ASM hättest? |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo Choose!
Ich brauch nix mehr in Delphi zu schreiben, weil es mit dem einfachen Cast prima funktioniert! :-D Schon peinlich, dass ich darauf nicht selber gekommen bin bei meinen wilden Cast Konstrukten. Ich danke Dir jedenfalls für Deine konstruktive Hilfe. :thuimb: Zur Info hier noch kurz ein Codeausschnitt:
Delphi-Quellcode:
Viele Grüsse
mov ebx, [eax].FMask // hier übertrage ich den Zeiger auf das Objekt FMask der Klasse TDIBMask ins Register ebx
cmp edx, TDIBMask([ebx]).FWidth // Nun ist der Zugriff auf die Variablen möglich! cmp edx, TDIBMask([eax].FMask).FWidth // Sowas wird durchaus compiliert aber falsch ausgewertet!!!! OLLI |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Korrekt, da FMask ein Zeiger ist der im "Record" eines Objectes steht, musst du selber dereferenzieren. Ein Machinenbefehl zum direkten derefernezieren mehrerer Referenzen existiert dafür nicht. Es liegt also nicht an Delphi oder Assembler, sondern einfach an den Möglichkeiten der CPU.
Desweiteren nutze nicht deine obige Art des "Typcast" in ASM. Besser ist:
Delphi-Quellcode:
Ab D7 ist deine obige Syntax ungültig.
asm
MOV EBX,[EAX].TMyClass.FMask CMP EAX,[EBX].TMaskClass.FRect.Left end; Gruß Hagen |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Zitat:
beide Varianten werden sowohl in D5 (Anforderung) als auch in D7 (Deine Aussage) zu idetischem Code übersetzt. Obwohl ich den Cast in der Form AType(AVar) aus Konsistentzgründen mit der übrigen Delphi Language als angenehmer finde und die Variante AVar.AType zu Doppeldeutigkeiten führen kann, sofern man sich nicht an Nameskonventionen hält, wird die von Dir dargestellte Variante in ASM-Abschnitten von Borland verwendet (zB Unit System). Ich denke, dass man aus diesem Grund tatsächlich die zweite Notation verwenden sollte. |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Nein, ab D7 funktionieren nur die zweite Notation als Typcast, bzw genauer gesagt als korrekter Qualifier eines Recordelementes. Denn die erste Notation ist ein Pascaltypischer Typcast, die zweite Notation aber ein in Asm reguklärer Strukturqualifier.
Delphi-Quellcode:
Beides wären regulär gültige Syntax, aber nur der erste Fall wird ab D7 durch den inline Asm akzeptiert. Betrachtet man meine obige Aussage was der Unterschied beider Syntax sind (Typcast <> Qualifier) dann ist dies auch logisch. Auch ich habe dies erneut lernen müssen :) und meine nun das es korrekt war in D7 diese Syntax zu straffen.
type
TMyObject = class FProc: procedure(const Data; DataSize: Integer) of object; end; procedure TMyObject.Calc(const Data; DataSize: Integer); assembler; asm JMP DWord Ptr [EAX].FProc.TMethod.Code // in D7 JMP TMethod([EAX].FProc).Code // bis D7 möglich end; Gruß Hagen |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Interessant, Hagen.
Delphi-Quellcode:
funktioniert unter D7 tatsächlich nicht,
JMP TMethod([EAX].FProc).Code
Delphi-Quellcode:
hingegen schon :gruebel:
JMP TMethod([EAX]).Code
Ich konnte leider nichts zu "struktur qualifier", "struktur qualifizierer", "structure qualifier", etc. in unserem Kontext finden. Könntest Du auf eine Quelle verweisen oder das Prinzip, dass Du entdeckt hast, näher darstellen? Vielen Dank! |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
"Ich" habe da nichts entdeckt.
Es ist üblich in Assembler einen qualifizierten Bezeichner zu benutzen. Statt also einen Zeiger zu typcasten = umzubiegen und dem Compiler weiszumachen das der untypisierte Zeiger vom korrekten Typ ist, wird bei einem qualifizierten Bezeichner durch die Qualifizierung an sich Typsicherheit erzeugt. Statt also
Code:
wobei aber der Unterschied in Assembler besteht das EAX als Register das Auto enthält aber von sich aus ohne Typ ist. D.h. Auto im obigen Beispiel wäre in PASCAL ein Typ mit Typisierung TAuto und in Assembler ein stinknormaler Zeiger. Deshalb ist ein qualifizierter Bezeichner in Asembler auch ein impliziter "Typcast". Da aber in Assembler noch nie Typsicherheit bestanden hat, und man sich diese aber wünschte, hat man angefangen in die asm-Syntax "Record Typen" mit obiger Syntax ein wenig besser Typsicher zu machen.TTier(Auto).Laufe wird Auto.TTier.Laufe Der Unterschied besteht also in der Denkweise. Ein Typcast soll einen bestehenden Typ so erscheinen lassen als wäre es ein anderer Typ. Damit hebelt ein Typcast die Sicherheiten der Typüberprüfung des Compilers aus. Ein qualifizierter Bezeichner soll dagegen aus einer Typlosigkeit eine Typsicherheit erschaffen. Auf die Frage in diesem Thread projeziert heisst das das ein PASCAL like Typcast nichts in Assembler zu suchen hat, und das in Assembler die qualifizierten Bezeichner benutzt werden sollten. Das eine zerstört Typsicherheit und das andere erschafft sie. Gruß Hagen |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo Hagen!
Vielen Dank für Deine Ausführungen. Es ist immer wieder ein Genuss, Deine Beträge zu studieren. Du hast folgendes Beispiel angeführt, wobei ich ehrlich gesagt noch nicht ganz verstehe, was der Code bezwecken soll.
Delphi-Quellcode:
Wieso verwendest Du den Operanten JMP und nicht CALL? Es geht doch darum, eine variable Methode zur Berechnung zu implementieren; ein für meine Begriffe sehr elegantes Programmierkonstrukt. Aber wie es geht nach dem Sprung zur Adresse Code und der Abarbeitung der Fkt weiter? Oder wird hier einfach der Stackframe der Methode Calc genutzt? Bitte um Aufklärung!
type
TMyObject = class FProc: procedure(const Data; DataSize: Integer) of object; end; procedure TMyObject.Calc(const Data; DataSize: Integer); assembler; asm JMP DWord Ptr [EAX].FProc.TMethod.Code // in D7 JMP TMethod([EAX].FProc).Code // bis D7 möglich end; Viele Grüsse OLLI |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Danke für Deine Ausführung Hagen, klar und schlüssig.
@OLLI: Da FProc identisch zur Methode Calc deklariert ist, ist in der dortigen Implementierung alles notwendige zum "Aufräumen" des Stacks und zum "Rückspringen" vorhanden (sofern FProc<>nil). Wolltest Du einen Call ausführen und wäre die Deklaration etwas komplexer, so dass nicht ausschließlich Register für die Überhabe verwendet werden oder wäre stattdessen ein stdcall oä verwendet worden, hättest Du diese Werte zunächst kopieren und erneut auf den Stapel legen müssen. In Hagens Implementierung hingegen, wird alles unangetastet gelassen und der Rücksprüng, der in FProc ausgeführt werden wird, nutzt die Adresse, die vom Klienten eigentlich für Calc gedacht war (ebenso verhält es sich mit den Parametern). Schön an der Lösung ist, dass man über den impliziten Paramter EAX und das Displacement (Offset des Attributs im Objekt) die Adresse der tatsächlich auszuführenen Methode "gratis mitbekommt". |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
HY Choose!
Viel gelernt von Euch beiden! :-D Also hab ich richtig vermutet. Dann ist auch sicher folgende Sicherheitsabfrage und Default-Berechnung möglich!? Wenn ihr schon mal da seid, quetsch ich euch auch aus.
Delphi-Quellcode:
OLLI
CMP [EAX].FProc, 0
JNE DWord Ptr [EAX].FProc.TMethod.Code // in D7 XOR EAX, EAX @Loop: ADD EAX, [EDX] INC EDX DEC ECX JNZ @Loop |
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Hallo OLLI,
ich gehe davon aus, dass Deine Implementierung nur Beispielhaft ist (es handelt sich um eine Prozedur, das Ändern von EAX bleibt daher ohne Effekt). Eine Default-Implementierung ist mit Sicherheit eine gute Sache, ich persönlich würde sie aber wiederum als Delphi-Methode implementieren und diese stattdessen absolut anspringen. Sofern Du nicht das letzte an Performance herausholen möchtest oder die Implementierung trivial ist (zB Result:= 0) würde ich immer zugunsten der Wartbarkeit und Übersicht entscheiden (zB mit Struktur-Qualifizierern ;)). Zwar macht Delphi keine Annahmen über irgendwelche Flags, allerdings möchte ich zu bedenken geben, dass der Vergleich
Code:
eben das Flagregister verändert. Solltest Du hinter FProc eine ASM-Implementierung legen, die auch aus anderen Situationen verwendet wird und dort weitere Informationen aus den Flags verwendet, solltest Du das noch berücksichten (weit hergeholt, ich weiß).
CMP [EAX].FProc, 0
|
Re: Delphi Inline Assembler Zugriff auf Privates Objekt
Zitat:
D.h. in EAX = Self, EDX = Data, ECX = Datasize, somit besteht der "Stackframe" in .Calc() nur aus der Rücksprungadresse. Ein CALL nach FProc würde also zusätzlich ein PUSH + CALL + RET mehr kosten als ein JMP. Die Methode in FProc kehrt also durch dem JMP sofort zum Aufrufer von .Calc() zurück. Man hätte also CALL nehmen können, aber warum ein PUSH + RET verschenken wenn man ein JMP nehmen kann ohne großen Aufwand im Quelltext zu machen. Es ging mir also nicht unbedingt darum den letzten Taktzyklus aus der CPU rauszuquetschen sondern nur darum das der Tipaufwand im Quelltext jeweils gleich ist, aber 2 Taktzyklen und ein paar Branches/Misses eleminiert werden. Wenn durch den JMP noch zusätzliche Parameteränderungen nötig gewesen wären dann hätte ich den CALL bevorzugt. Nungut, es sollte auch nur ein Beweis sein das ab D7 der inline Assembler strenger ist als in der Hilfe beschrieben wird. Gruß Hagen |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:24 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz