Portierungsproblem mit Assembler, Register

[Schorschi5566]

Hallo DP,

ich versuche die DEC-Library von Hagen nach Lazarus zu porten.

An einer Stelle in der CRC.pas bekomme ich die Fehlermeldung:

Fatal: Syntax error, "identifier" expected but "register" found

Delphi-Quellcode:

// initilaize CRC Definition with a custom Algorithm
function CRCSetup(var CRCDef: TCRCDef; Polynomial, Bits, InitVector, FinalVector: Cardinal; Inverse: LongBool): Boolean;

implementation

function CRCSetup(var CRCDef: TCRCDef; Polynomial, Bits, InitVector,
  FinalVector: Cardinal; Inverse: LongBool): Boolean; register;
asm // initialize CRCDef according to the parameters, calculate the lookup table
       CMP   ECX,8
       JB    @@8
       PUSH  EBX
       PUSH  EDI
       PUSH  ESI
       MOV   [EAX].TCRCDef.Polynomial,EDX  // <<< Hier kommt der Fehler!
       MOV   [EAX].TCRCDef.Bits,ECX
       MOV   EBX,InitVector
       MOV   EDI,FinalVector
       MOV   ESI,Inverse
       MOV   [EAX].TCRCDef.CRC,EBX
       MOV   [EAX].TCRCDef.InitVector,EBX
       MOV   [EAX].TCRCDef.FinalVector,EDI
       MOV   [EAX].TCRCDef.Inverse,ESI
       XOR   EDI,EDI
       LEA   EBX,[ECX - 8]
       SUB   ECX,32
       DEC   EDI
       NEG   ECX
       SHR   EDI,CL
       MOV   [EAX].TCRCDef.Shift,EBX
       MOV   [EAX].TCRCDef.Mask,EDI
       TEST  ESI,ESI
       JZ    @@5
       XOR   EBX,EBX
       MOV   ECX,[EAX].TCRCDef.Bits
@@1:   SHR   EDX,1
       ADC   EBX,EBX
       DEC   ECX
       JNZ   @@1
       NOP
       MOV   ECX,255
       NOP
@@20:  MOV   EDX,ECX
       SHR   EDX,1
       JNC   @@21
       XOR   EDX,EBX
@@21:  SHR   EDX,1
       JNC   @@22
       XOR   EDX,EBX
@@22:  SHR   EDX,1
       JNC   @@23
       XOR   EDX,EBX
@@23:  SHR   EDX,1
       JNC   @@24
       XOR   EDX,EBX
@@24:  SHR   EDX,1
       JNC   @@25
       XOR   EDX,EBX
@@25:  SHR   EDX,1
       JNC   @@26
       XOR   EDX,EBX
@@26:  SHR   EDX,1
       JNC   @@27
       XOR   EDX,EBX
@@27:  SHR   EDX,1
       JNC   @@28
       XOR   EDX,EBX
@@28:  MOV   [EAX + ECX * 4],EDX
       DEC   ECX
       JNL   @@20
       JMP   @@7
@@5:   AND   EDX,EDI
       ROL   EDX,CL
       MOV   EBX,255
// can be coded branchfree
@@60:  MOV   ESI,EBX
       SHL   ESI,25
       JNC   @@61
       XOR   ESI,EDX
@@61:  ADD   ESI,ESI
       JNC   @@62
       XOR   ESI,EDX
@@62:  ADD   ESI,ESI
       JNC   @@63
       XOR   ESI,EDX
@@63:  ADD   ESI,ESI
       JNC   @@64
       XOR   ESI,EDX
@@64:  ADD   ESI,ESI
       JNC   @@65
       XOR   ESI,EDX
@@65:  ADD   ESI,ESI
       JNC   @@66
       XOR   ESI,EDX
@@66:  ADD   ESI,ESI
       JNC   @@67
       XOR   ESI,EDX
@@67:  ADD   ESI,ESI
       JNC   @@68
       XOR   ESI,EDX
@@68:  ROR   ESI,CL
       MOV   [EAX + EBX * 4],ESI
       DEC   EBX
       JNL   @@60
@@7:   POP   ESI
       POP   EDI
       POP   EBX
@@8:   CMC
       SBB   EAX,EAX
       NEG   EAX
end;

Kommt Free Pascal nicht mit "register" klar? Aber dann müsste doch der Fehler schon bei der Deklaration kommen, oder?

Oder kann mir bitte jemand helfen, den ASM-Code umzuschreiben, so dass die Parameterübergabe ganz normal ohne register funktioniert?


Grüße,
Uwe

[himitsu]

Eventuell kommt der ja mit "Polynomial" durcheinander, welches auch noch als als Funktionsparameter existiert.

[Schorschi5566]

Hallo Himitsu,

wenn man
MOV CRCDef.Polynomial,EDX
verwendet, "schluckt" er es. Bei TCRCDef.Bits ist es das Gleiche. Die übrigen Parameter funktionieren so wie angegeben. Hat wohl was damit zu tun, dass die ersten drei Parameter sowieso in Registern abgelegt werden.

Habe meinen Versuch aber erstmal auf Eis gelegt. Für Plattformunabhängigkeit wäre es besser, wenn alles in Pascal geschrieben wäre und dazu muss ich mir erstmal die ASM-Routinen genauer anschauen.

Aber danke für die Antwort.

[gammatester]

Zitat von Schorschi5566:

Habe meinen Versuch aber erstmal auf Eis gelegt. Für Plattformunabhängigkeit wäre es besser, wenn alles in Pascal geschrieben wäre und dazu muss ich mir erstmal die ASM-Routinen genauer anschauen.

Warum so schnell aufgeben? Meine Opensource CRC-Modelunit ist explizit auch für FreePascal/Lazurus und hat schon über 50 vordefinierte Rocksoft-CRC-Modelalgorithmen. Selbstverständlich gibt's für Speedfans auch schnelle Algorithmen, zB die FastCRC32 mit 'sclicing by 4' (ca 4 Zyklen pro Byte mit BASM oder ca 19 Zyklen pro Byte mit purem Freepascal).

Gruß Gammatester

[Schorschi5566]

Hallo Gammatester,

im Wesentlichen geht's bei mir darum eine eigene fertige Win-Delphi-Anwendung für Mac OS X zur Verfügung zu stellen.

Die DEC-Routinen habe ich verwendet um zwischen dem Programm und 'ner PHP-Anwendung auf 'nem Webserver verschlüsselt zu kommunizieren. Soll eigentlich nur sniffersicher sein, mehr nicht.

Eventuell brauche ich die CRC.pas nicht mal. Soweit hab ich mich noch gar nicht in Hagens Paket reingearbeitet. Sollte ich dafür vielleicht mal tun.

Du meinst also, dass man die CRC.pas im Prinzip durch deine ersetzen könnte, oder wie?


Grüße,
Uwe

[implementation]

Zitat von Schorschi5566:

Kommt Free Pascal nicht mit "register" klar?

Doch. Aber vielleicht liegt es daran, dass es im Interface-Teil nicht explizit angegeben ist. Entweder immer angeben, oder gar nicht.
Das wäre jetzt mal so meine Theorie.
Ich sollte den Quellcode mal genauer lesen, ich dachte jetzt, es ginge um das Schlüsselwort

[himitsu]

Notfalls kannst du den Offset auch manuell aufrechnen.

[EAX].TCRCDef.Polynomial quasi als [EAX+8] (oder wie groß halt der Offset ist)

Es kann natürlich auch sein, daß FPC sowas kann, aber eine andere Syntax verwendet,
bzw. hast du den FPC mal in den delphi-kompatiblen Modus {$mode delphi} versetzt?

[NamenLozer]

Ging nicht auch [EAX+TCRCDef.Polynomial] ? Keine Ahnung, inwiefern das unter FPC gilt.

[himitsu]

Sowas TCRCDef[EAX].Polynomial , in der Art, hab ich (glaub ich zumindest) auch schonmal irgendwo gesehn.

[Schorschi5566]

Danke für eure Antworten.

Der Delphi-Mode war schon eingeschaltet.

MOV CRCDef.Polynomial,EDX ist ja nix anderes als MOV [EAX].TCRCDef.Polynomial, EDX das würde schon passen, denke ich...

Dieses Problem ist wohl noch zu lösen. Allerdings ist der ASM-Anteil am DEC doch recht hoch und es geht dann mit solchen Sachen weiter...

Generating PIC, but reference is not PIC-safe
Da musste ich erstmal googlen, was das überhaupt bedeutet. Es geht um die Verwendbarkeit des Codes in DLLs unter Linux, oder so.
Wenn ich auf die Art weiterporte kommt hinten garantiert irgendwas raus, was sich zwar kompilieren lässt, aber mit DEC nicht mehr allzuviel zu tun haben dürfte.

Zwischenzeitlich habe ich mal in DCPCrypt für Lazarus reingeschnuppert. Nicht so schön und umfangreich wie DEC aber wohl für meine Zwecke nutzbar. Ich glaube, so rum wird das schmerzloser.