XE2: ASM und Pascal gemischt?

[Schorschi5566]

Hallo DPler,

ich habe gerade den von mir bevorzugten SQLite3-Wrapper in XE2 (Win32) an den Start gebracht. Funktioniert soweit, wie erwartet. Also das Ganze mal für die Win64-Plattform probiert... :shock: (dass die DLL im Moment nur in der 32Bit-Version vorliegt, sollte mit dem Problem erstmal nichts zu tun haben)

Eine erste Besonderheit des Wrappers ist, dass er Funktionen der SQLite-DLL erst bei Bedarf lädt.

Dazu verwendet der Wrapper beispielsweise folgenden Code:

Delphi-Quellcode:

var
  _SQLite3_Open: Pointer;

function SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;
begin
  if _SQLite3_Open = nil then
    LoadProcAddress(_SQLite3_Open, 'sqlite3_open');
  asm
    MOV     ESP, EBP
    POP     EBP
    JMP     [_SQLite3_Open]
  end;
end;

Beim Kompilieren für die Win64-Plattform stolpert er nun über die ASM-Anweisung.

Meldung: [DCC Fehler] SQLite3Wrapper.pas(360): E1025 Sprach-Feature wird nicht unterstützt: 'ASM'

Frage: Liegt es wieder daran, dass ich noch mit der Trial "rummache" oder geht sowas tatsächlich nicht mehr?
Oder liegt's an der Angabe der calling convention, die es ja in der Form unter Win64 nicht mehr gibt. "cdecl" weglassen hat aber nichts geändert.


Grüße,
Uwe

[Namenloser]

Inline-Assembler gibt es für 64bit leider nicht...

[daywalker9]

Du kannst bei x64 kein Inline Assembler mehr nutzen, nur noch reine ASM Funktionen.

[implementation]

Das große Problem an den Assembler-Statements ist, dass sie nicht portierbar sind.
Das steht den neuen Cross-Platform-Zielen ziemlich im Wege.

Unter anderem hat nämlich AMD64/Intel64 eben auch ein anderes Instruction-Set als die IA-32, für die der Code bestimmt ist.
Genauso ist Segment-Adressierung dort keine gängige Praxis mehr, sondern es wird nur noch linear adressiert.
Somit müsstest du nun so oder so alle ASM-Statements umschreiben.

Ich selbst habe kein XE2, kann deshalb keine festen Aussagen treffen, ob das Feature noch verfügbar ist.
Aber ich gehe davon aus, dass man es für 64-Bit rausgenommen hat.

[daywalker9]

ASM grundsätzlich funktoniert noch. Nur haben sich dort die Register, das Alignment und die Größen der Register geändert (klar ist ja nun alles größer).

Aber um auf die nächsten Compiler änderungen vorbereitet zu sein (ARM?!) sollte man puren Pascal-Code nutzen.

[Stevie]

Bei dem konkreten Problem sollte die Lösung ja null problemo sein, einfach _SQLite3_Open nicht als puren Pointer sondern typisiert mit der richtigen signatur deklarieren und dann einfach aufrufen.

[jaenicke]

An der Stelle mit Assembler zu arbeiten... :shock: Wie kommt man denn auf so komische Ideen?

Sauber und typsicher mit Delphiquelltext ist das doch erstens viel einfacher und zweitens weniger fehleranfällig.

(Auch wenn theoretisch die Möglichkeit besteht, die ganze Methode als Assemblerfunktion umzuschreiben. Aber dann fängst du bei ARM wieder an umzuschreiben...)

[daywalker9]

Zitat:

Zitat von jaenicke (Beitrag 1123339)

An der Stelle mit Assembler zu arbeiten... :shock: Wie kommt man denn auf so komische Ideen?

Sauber und typsicher mit Delphiquelltext ist das doch erstens viel einfacher und zweitens weniger fehleranfällig.

Keine Ahnung - hab ich schon öfter mal gesehen, wo Funktionen einer Dll so geladen und aufgerufen wurde.

[Schorschi5566]

Danke für Eure Antworten. Jepp, leuchtet ein, dass das nicht gerade multiplattformfreundlich ist. :lol:

So wie's der Wrapper gemacht hat, konnte man das gut mit dem DLL2MemoryModule von Martin Offenwanger kombinieren und die DLL direkt aus einer Ressource verwenden ohne den Umweg die DLL temporär ins Filesystem laden zu müssen. Aber mit Funktionspointern sollte das natürlich auch gehen.


P.S.: Der Vorteil den der Autor des Wrappers darin gesehen hat, dürfte sein, dass man keinen "doppelten" Funktionsaufruf macht, sondern die DLL-Funktion den Rücksprung direkt machen kann.

[bernau]

Auf den Delphitagen wurde gesagt, daß in einer Procedure bei 64Bit entweder Pascal-Code drinstehen darf ODER Assembler. Musst also den Assemblerteil in eine Procedure auslagern.

[daywalker9]

Oder besser: Typen dafür definieren und diesen nutzen.

[jaenicke]

Zitat:

Zitat von Schorschi5566 (Beitrag 1123344)

P.S.: Der Vorteil den der Autor des Wrappers darin gesehen hat, dürfte sein, dass man keinen "doppelten" Funktionsaufruf macht, sondern die DLL-Funktion den Rücksprung direkt machen kann.

// EDIT:
Ok, ich sehe es, aber wo liegt da der große Vorteil? Die paar Mikrosekunden Zeitersparnis?

[Schorschi5566]

Zitat:

Ok, ich sehe es, aber wo liegt da der große Vorteil? Die paar Mikrosekunden Zeitersparnis?

Wird sich zeigen. Werde dann mal die Win32 und die Win64-Version vergleichen. Wirkt sich wahrscheinlich eh erst ab ein paar Millionen Aufrufen auf der Stopuhr aus. ;)

[Insider2004]

Seit XE2 gilt mehr denn je: weg mit dem Assembler-Zeugs! Pascal ist mittlerweile genauso schnell. Und es entfällt das ständige Neuschreiben beim Portieren. Die beste Performance erreicht man durch gescheite Algorithmen, nicht durch Assembler.

[USchuster]

Assembler hat für gewisse Bereiche und Probleme durchaus seine Berechtigung. Der heutige 0815 Programmier sollte darauf verzichten und lieber den Compiler optimierten Code erzeugen lassen, wobei sich das Verzichten ohnehin oft durch die fehlenden Kenntnisse erübrigt. Assemblerunterstützung war ursprünglich nicht für Win64 im XE2 geplant und die Lösung zur Nutzung von Assembler wäre dann das Einbinden von Objektdateien von z.B. NASM gewesen. Das es Assemblerunterstützung doch gibt, liegt daran das die entsprechende Nachfrage besteht.

[Stevie]

Zitat:

Zitat von USchuster (Beitrag 1123409)

Assemblerunterstützung war ursprünglich nicht für Win64 im XE2 geplant und die Lösung zur Nutzung von Assembler wäre dann das Einbinden von Objektdateien von z.B. NASM gewesen. Das es Assemblerunterstützung doch gibt, liegt daran das die entsprechende Nachfrage besteht.

Wenn ich mir so manche RTL Units anschaue, frag ich mich, wie sie es sonst selber relativ unkompliziert hinbekommen hätten.

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1123403)

Pascal ist mittlerweile genauso schnell.

Naja, das stimmt zumindest so allgemein nicht. Wenn man sich den generierten Assemblercode angeht, sieht man, dass es da durchaus Optimierungspotential gibt.

Es gibt aber nicht viele Fälle, bei denen der relativ kleine Performancegewinn wirklich ins Gewicht fällt. In diesen Fällen kann es sich aber dann durchaus lohnen Assembler einzusetzen, auch wenn das heißt, dass man den Code für verschiedene Plattformen mehrfach schreiben muss. Das ist dann aber auch nicht so schlimm, weil es eben nicht so viele Fälle sind.

[Schorschi5566]

Zitat:

Die beste Performance erreicht man durch gescheite Algorithmen, nicht durch Assembler.

Sehr oft lassen sich "gescheite" Algorithmen aber mit Assembler richtig gut optimieren.

Aber wie Sebastian Jaenicke schon schreibt. Es muss sich schon lohnen, wenn man in die ASM-Kiste greift... ;)

Hatte gehofft, der Compiler würde den überflüssigen Aufruf zu 'nem Jump optimieren, tut er aber nicht.

[himitsu]

- Lade alles statisch.
- Lade doch alle Adressen gleich zu Beginn und springe danach direkt hin, ohne den Wrapper.
oder
- Lade überall erstmal Laderoutinen rein und tausche diese, beim ersten Aufruf, aus.

Delphi-Quellcode:

interface

var
  SQLite3_Open: function(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;

implementation

function _SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;
begin
  LoadProcAddress(SQLite3_Open, 'sqlite3_open');
  Result := SQLite3_Open(filename, db);
end;

initialization

SQLite3_Open := _SQLite3_Open;

Ich weiß jetzt nicht, wie das mit Konstanten in Mac oder 64 Bit aussieht, aber früher hätte ich eventuell eine typisierte Konstante mißhandelt, anstatt der globalen Variable (da diese grungsätzlich erstmal schreibgeschützt ist, was sich aber verbiegen läßt)

[samso]

Dieser ASM-Trick wird häufig verwendet (z.B. Jedi-Projekt). Es gibt drei Vorteile:
1) Es braucht nicht jedesmal eine individuelle global variable deklariert zu werden. Wenn man nur eine Funktion wrappen muss spielt das keine Rolle, aber bei 150 Funktionen macht einen dieses ständige Copy&Paste schon ganz schön müde.
2) Die Parameter, die sich ja sowieso schon auf dem Stack befinden, werden nicht nochmal auf den Stack kopiert
3) Ein sicherlich zu vernachlässigender Zeitvorteil beim Sprung/Rücksprung in die eigentliche Routine

Wenn der Compiler eine Aufrufkonvention unterstützen würde, bei der die Parameter nicht nochmals kopiert werden müssten, könnte man sich den Umweg über Assembler sparen. Ich würde mir so etwas wünschen (entsprechend des Aufrufs "inherited;"):

Delphi-Quellcode:

var
   _SQLite3_Open: FARPROC;

function SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;
begin
   if _SQLite3_Open = nil then
     LoadProcAddress(_SQLite3_Open, 'sqlite3_open');
   _SQLite3_Open;
end;

[jaenicke]

Zitat:

Zitat von samso (Beitrag 1123444)

Wenn man nur eine Funktion wrappen muss spielt das keine Rolle, aber bei 150 Funktionen macht einen dieses ständige Copy&Paste schon ganz schön müde.

Wer macht das denn schon manuell? ;-)

[samso]

Wenn Du mir jetzt auch noch einen funktionierenden Automaten nennen würdest?

[jaenicke]

Ich habe mir dafür selbst schnell einen Experten geschrieben. Dem muss ich allerdings noch nested types und Generics beibringen (der war für D2006), aber zumindest als reiner Generator in einer neuen Unit wäre er schon fertig.

Und das zum Generieren als externes Tool sind ja nur ein paar Minuten Arbeit, oder?