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:

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Schorschi5566 (Beitrag 1104980)

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

Zitat von Schorschi5566 (Beitrag 1104922)

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 :oops:

[himitsu]

Notfalls kannst du den Offset auch manuell aufrechnen.

Delphi-Quellcode:

[EAX].TCRCDef.Polynomial

quasi als

Delphi-Quellcode:

[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

Delphi-Quellcode:

{$mode delphi}

versetzt?

[Namenloser]

Ging nicht auch

Delphi-Quellcode:

[EAX+TCRCDef.Polynomial]

? Keine Ahnung, inwiefern das unter FPC gilt.

[himitsu]

Sowas

Delphi-Quellcode:

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

Delphi-Quellcode:

Generating PIC, but reference is not PIC-safe

Da musste ich erstmal googlen, was das überhaupt bedeutet. :D 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. :stupid:

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.

[JamesTKirk]

Drei Punkte:
1. Würdest du eventuell das Problem, dass du im ersten Beitrag geschildert hast bitte im BugTracker von Free Pascal melden? Dann haben die FPC Entwickler nämlich die Gelegenheit den Fehler zu beheben :D

2. Wirf mal bitte einen Blick in die Unit crc (zu finden in $FPCDIR/packages/hash/src), vielleicht reicht das ja für deine Anwendung (wobei ich dir natürlich nicht ausreden möchte DEC zu portieren :mrgreen: )

3. Du könntest wegen dem PIC Problem mal auf der FPC Mailing Liste nachfragen. Ich kann dir da leider grad nicht weiterhelfen, da ich mit PIC noch nicht wirklich auseinander gesetzt habe.

Gruß,
Sven

[Schorschi5566]

Hallo Sven,

Zitat:

Zitat von JamesTKirk (Beitrag 1105633)

Drei Punkte:
1. Würdest du eventuell das Problem, dass du im ersten Beitrag geschildert hast bitte im BugTracker von Free Pascal melden? Dann haben die FPC Entwickler nämlich die Gelegenheit den Fehler zu beheben :D

Bin mir eigentlich gar nicht sicher, dass das ein Fehler in FPC ist. Obwohl, im Delphimode sollte er es eigentlich schlucken. :) Ok, werde ich machen.

Zitat:

Zitat von JamesTKirk (Beitrag 1105633)

2. Wirf mal bitte einen Blick in die Unit crc (zu finden in $FPCDIR/packages/hash/src), vielleicht reicht das ja für deine Anwendung (wobei ich dir natürlich nicht ausreden möchte DEC zu portieren :mrgreen: )

'Ne DEC-Portierung wäre schon deshalb toll, weil man dann nicht sämtliche irgendwann mal verschlüsselten Strings mit 'ner anderen Methode neu verschlüsseln müsste. :P Allerdings glaube ich, dass es mit Hagens Hilfe deutlich einfacher wäre, falls er Zeit dafür hat. Ich schau mir aber mal die Unit an, danke.

Zitat:

Zitat von JamesTKirk (Beitrag 1105633)

3. Du könntest wegen dem PIC Problem mal auf der FPC Mailing Liste nachfragen. Ich kann dir da leider grad nicht weiterhelfen, da ich mit PIC noch nicht wirklich auseinander gesetzt habe.

Geht mir irgendwie genauso. :stupid:

Grüße,
Uwe

[negaH]

nicht so schnell aufgeben, versuche

Delphi-Quellcode:

asm
  MOV [EAX + OFFSET TCRCDef.Polynomial], EDX
end;

Ich finde die andere Schrebweise aber "OOP ähnlicher" und deshalb nutzte ich sie, besonders auch beim ASM Zugriff auf Delphi Objekte und Klassen.
Normalerweise sollte das FPC aber im Delphi Mode unterstützen, dh. der Inline Assembler scheint nicht 100% kompatibel zu sein,

Gruß Hagwe

[negaH]

Um die Fragestellung zu beantworten warum ich es so und nicht anders programmiert habe, besonders in Sicht auf die Verwendung des Funktionszeigers als Adresse auf eine im Codesegment gespeicherte Tabelle.

Ich hatte damals drei Ziele mit der CRC Unit:

1.) Unterstützung aller CRCs mit bis zu 32Bit
2.) extrem kompakter Code
3.) ausschließliche Nutzung des Codesegmentes also kein DATA und BSS Segment notwendig.

Letzterer Punkt ist wichtig wenn das DATA/BSS Segment der Zielanwendung nicht das der eigentlichen Anwendung ist die den CRC Code enthält. Wer zwischen den Zeilen lesen kann weiß worauf das hinausläuft.

Gruß Hagen

[Schorschi5566]

Hallo Hagen,

danke für die Antworten. Das Problem war eigentlich schon gelöst.

Zitat:

Zitat von Schorschi5566 (Beitrag 1105140)

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

Delphi-Quellcode:

Generating PIC, but reference is not PIC-safe

Da musste ich erstmal googlen, was das überhaupt bedeutet. :D 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. :stupid:

Das PIC-Problem trat hier auf, wenn ich mich nicht irre: (Handelt sich wohl um eine globale Referenz auf FCRC16. Könnte man vielleicht lösen, wenn man FCRC16 als Parameter übergibt)

Delphi-Quellcode:

function CRC16(CRC: Word; const Buffer; Size: Cardinal): Word;
asm
       JECXZ @@2
       PUSH  EDI
       PUSH  ESI
       MOV   EDI,ECX
{$IFDEF PIC}
       MOV   ESI,[EBX].FCRC16 // hier kracht's auch! Not PIC-Safe
{$ELSE}
       MOV   ESI,FCRC16
{$ENDIF}
       XOR   ECX,ECX
       TEST  ESI,ESI
       JZ    @@3
@@1:   MOV    CL,[EDX]
       XOR    CL,AL
       SHR   EAX,8
       INC   EDX
       XOR   EAX,[ESI + ECX * 4]
       DEC   EDI
       JNZ   @@1
       POP   ESI
       POP   EDI
@@2:   RET
@@3:   PUSH  EAX
       PUSH  EDX
       CALL  CRC16Init
       MOV   ESI,EAX
       XOR   ECX,ECX
       POP   EDX
       POP   EAX
       JMP   @@1
end;

Der Fehler kommt unabhängig davon ob PIC definiert ist oder nicht.


Wahrscheinlich wird es noch einige Stellen im Code von DEC geben, über die FPC oder Lazarus stolpert. Wenn ich dich dann jedesmal nerven darf, würde ich weitermachen. ;)


Grüße,
Uwe

[negaH]

Zitat:

Zitat von Schorschi5566 (Beitrag 1106579)

Hallo Hagen,

Wahrscheinlich wird es noch einige Stellen im Code von DEC geben, über die FPC oder Lazarus stolpert. Wenn ich dich dann jedesmal nerven darf, würde ich weitermachen. ;)

Ja kannst mich nerven, EMail hast du per PN bekommen. Allerdings kenne ich mit der Linux/Cylix Geschichten nicht praktisch aus. Das Register EBX stellt in diesen Betriebsystemen einen wichtigen Zeiger für die Anwendung dar. EBX darf nicht zerstört werden und hat eine ähnliche Funktion wie ein Threadcontext im Windows (benutzen aber die extended Segment Register der Intel CPUs, FS,GS Register usw).

Damals war Freepascal noch keine Alternative für mich, heute würde ich das DEC nur damit entwickeln wollen. Da Cylix ziemlich schnell tot war habe ich die Kompatiblität dahingehend aufgegeben. Denoch die schon enthaltenen Stellen nicht wieder entfernt.

Du solltest dich also in diese Thematik einarbeiten, informierst mich über die Forderungen die erfüllt werden müssen und dann kann ich dir fast aus dem Stegreif sagen was du wo im Source überprüfen musst.

Andererseits musst du für dich entscheiden ob sich letzendlich der Aufwand lohnt. So ist das eben mit Assembler und schlechterer Portierbarkeit. Die Argumente sowas in PASCAL Source zu machen sind nicht von der Hand zu weisen, wenn man nicht unbedingt das Meiste rausholen will.

Gruß Hagen

[negaH]

Zitat:

Das PIC-Problem trat hier auf, wenn ich mich nicht irre: (Handelt sich wohl um eine globale Referenz auf FCRC16. Könnte man vielleicht lösen, wenn man FCRC16 als Parameter übergibt)

Das würde ich nicht anraten. So veränderst du die angedachte Funktionsweise. Wenn du nur CRC.pas benutzen möchtest denke ich ist das legitim, aber im Kontext vom DEC würde ich es richtig machen.

Wir müssen nur wissen wie wir im inline Assembler korrekt auf globale Variablen und Funktionsaddressen zugreifen können. Das geht über das Register EBX. Entscheidend ist die korrekte Syntax und Informationen wann man diese Zugriffsvariante benutzen muß und wann nicht.

Gruß Hagen

[mkinzler]

In Anbetracht der Änderungen im 64Bit-Compiler und geplanter weiterer Prozessorplattformen, sollte man vielleicht auf inline Assembler oder sogar Assembler komplett verzichten

[Schorschi5566]

Zitat:

Zitat von negaH

Das würde ich nicht anraten. So veränderst du die angedachte Funktionsweise.

War nur so eine schnelle Idee, dachte mir schon, dass du dir was dabei gedacht hast. :D

Zitat:

Zitat von mkinzler (Beitrag 1106631)

In Anbetracht der Änderungen im 64Bit-Compiler und geplanter weiterer Prozessorplattformen, sollte man vielleicht auf inline Assembler oder sogar Assembler komplett verzichten

Sehe ich auch so und habe mal USEASM in der Ver.inc undefined. Führt leider dazu, dass DEC auch nicht mehr unter Delphi durchkompiliert.

Delphi-Quellcode:

[DCC Fehler] DECUtil.pas(768): E2029 'BEGIN' erwartet, aber 'INITIALIZATION' gefunden

Irgendwo fehlt da wohl ein $ENDIF, oder? Aber wo? :?

Ansonsten werde ich jetzt erstmal versuchen DEC 5.2 (was ist eigentlich mit DEC 5.3?) unter Windows mit Lazarus/FPC lauffähig zu bekommen.

Assembler kann man schon verwenden, denke ich. Die meisten von Lazarus/FPC unterstützten Plattformen laufen eh mit Intelprozessoren. Schön wäre aber, wenn man für alle ASM-Routinen eine Pascal-Variante hätte, dann könnte man immer noch einzelne Plattformen mit entsprechenden ASM-Funktionen optimieren. Passiert in der Lazarus-Community normalerweise fast automatisch.


Grüße,
Uwe

[Schorschi5566]

Hmm, für Win32 läuft's schonmal mit Lazarus. Dabei kommt offenbar die PIC-Problematik nicht zum Tragen.

Trotzdem, war einfacher als gedacht. :D

@Hagen: Hast du ein Testprogramm womit man mal weite Teile der DEC ausprobieren kann, oder so? Ich habe nur mal schnell einen Encrypt/Decrypt-Versuch gemacht, der funktioniert. Auch mit unter Delphi codierten Strings.

Das hat geklappt:

Delphi-Quellcode:

function EncryptString(const Password: RawByteString;
  const Value: RawByteString): RawByteString;
var
  Salt, SessionKey: Binary;
begin
  Salt := RandomBinary(16);
  with TCipher_Rijndael.Create do
    try
      SessionKey := THash_SHA1.KDFx(Password, Salt, Context.KeySize,
        TFormat_Copy);
      mode := cmCFS8; // ein 8Bit Feedback Modus ist für kurze Datenmengen sicherer
      Init(SessionKey);
      result := TFormat_MIME64.Encode(Salt + EncodeBinary(Value, TFormat_Copy));
    finally
      Free;
      ProtectBinary(Salt);
      ProtectBinary(SessionKey);
    end;
end;

[JamesTKirk]

Zitat:

Zitat von negaH (Beitrag 1106522)

nicht so schnell aufgeben, versuche

Delphi-Quellcode:

asm
  MOV [EAX + OFFSET TCRCDef.Polynomial], EDX
end;

Ich finde die andere Schrebweise aber "OOP ähnlicher" und deshalb nutzte ich sie, besonders auch beim ASM Zugriff auf Delphi Objekte und Klassen.
Normalerweise sollte das FPC aber im Delphi Mode unterstützen, dh. der Inline Assembler scheint nicht 100% kompatibel zu sein,

Gruß Hagwe

Deswegen habe ich ja auch gemeint, dass Schorschi einen Bug melden soll. Wahrscheinlich hat noch niemand den Inline Assemler derartig getestet. :?

Zitat:

Zitat von mkinzler (Beitrag 1106631)

In Anbetracht der Änderungen im 64Bit-Compiler und geplanter weiterer Prozessorplattformen, sollte man vielleicht auf inline Assembler oder sogar Assembler komplett verzichten

Solange eine entsprechende Pascal Alternative des Assemblercodes zur Verfügung steht, sehe ich kein Problem mit (Inline) Assembler. Mit dem passenden ifdefs sehe ich da kein Problem.

Zitat:

Zitat von Schorschi5566 (Beitrag 1106865)

Hmm, für Win32 läuft's schonmal mit Lazarus. Dabei kommt offenbar die PIC-Problematik nicht zum Tragen.

Trotzdem, war einfacher als gedacht. :D

Das ich nicht auf die Idee gekommen bin dir das vorzuschlagen :wall:
PIC findet nur unter Linux (oder Unix allgemein?) Anwendung. Bei Windows werden beim Start einer Anwendung die Adressen, welcher in der EXE abgelegt sind an die eigentliche Adresse verschoben (relocation). Deswegen ist keine "Global Offset Table" wie unter Linux nötig (welche eben auf x86 normal in EBX liegt).

Gruß,
Sven

[Schorschi5566]

Hallo Sven,

den "Bug" habe ich mal gemeldet. ;)

DEC erstmal auf Win32 zu porten ist gut und schön, aber ich brauche die Library eigentlich eher unter Linux bzw. Mac OS X. War sozusagen erstmal 'ne Fingerübung. :D

Gibt auch noch unter Win32 ein paar Merkwürdigkeiten aber dazu habe ich mal Hagen 'ne Mail geschrieben.

Sobald es Fortschritte in Sachen "DEC für Linux" gibt, melde ich mich hier wieder. 8-)


Grüße,
Uwe

P.S.: Die Schreibweise mit "MOV [EAX + OFFSET TCRCDef.Polynomial], EDX" funktioniert auch nicht. Das hat aber meiner Meinung nach etwas mit der Deklaration als register-Funktion zu tun. Er "frißt" die Schreibweise ja in anderen Situationen.

[JamesTKirk]

Zitat:

Zitat von Schorschi5566 (Beitrag 1107122)

den "Bug" habe ich mal gemeldet. ;)

Er scheint mittlerweile behoben zu sein. Es gibt aktuell leider keinen Schnappschuss, der aktuell genug ist, also müsstest du entweder warten, bis das wieder funktioniert (einfach diesen FTP Ordner im Auge behalten) oder versuchen FPC selbst zu kompilieren.

Gruß,
Sven

[schöni]

@Schorschi: Mal so als Gedanke:

Für welche Plattform ligt denn bisher funktionierender Code vor. Ich denke in Richtung Threads. Wenn es für die Zielplattform funktionierenden Code, welcher Programmiersprache auch immer gibt, sollte es möglich sein, ein Programm in der Quellsprache zu schereiben, das bei Eingabe die verschlüsselten Ausgaben liefert. Dann kann dieses Programm im Thread von der diesen Codierer nutzenden Anwendung als .exe gestartet werden, um das Ergebnis zu liefern.