Portierungsproblem mit Assembler, Register

[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

[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

[negaH]

Zitat von Schorschi5566:

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

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

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.

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

@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;