Portierungsproblem mit Assembler, Register

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

[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

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 )

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

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 von JamesTKirk:

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 )

'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. 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 von JamesTKirk:

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.

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

[JamesTKirk]

Zitat von 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

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

Zitat von mkinzler:

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

Das ich nicht auf die Idee gekommen bin dir das vorzuschlagen
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.

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.


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 von Schorschi5566:

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.

[Schorschi5566]

Hallo Hagen,

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

Zitat von Schorschi5566:

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.

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