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... (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:

zusammenfalten · markieren

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

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

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

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.

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.

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.

An der Stelle mit Assembler zu arbeiten... 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...)

Zitat von jaenicke:

An der Stelle mit Assembler zu arbeiten... 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.

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

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.

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.