Rotate in Delphi-Language?

[himitsu]

Moin moin,

warum gibt es eigentlich nur SHL und SHR, aber z.B. nicht ROL und ROR in der Delphi-Language?

Ja, man kann das z.B. via Assembler lösen, aber Inline-Assembler gibt jes ja nicht mehr (Win64 - innerhalb von Prozeduren), sondern nur noch als ganze Funktionen, wo das Inline auch nicht (richtig) funktioniert.

Delphi-Quellcode:

function ROL(Value: Integer; Count: Byte): Integer; inline;
asm
  ROL EAX, DL
end;

Aber vorallem in Bezug auf Multiplattform macht sich Assembler eh nicht so gut
und sowas wie

Delphi-Quellcode:

(a shl i) or (a shr (32-i))

ist doch auch nicht wirklich eine schöne Lösung, vorallem da doch praktisch alle CPUs solche Befehle direkt unterstüzen.

[BUG]

Zitat:

Zitat von himitsu

Aber vorallem in Bezug auf Multiplattform macht sich Assembler eh nicht so gut
und sowas wie

Delphi-Quellcode:

(a shl i) or (a shr (32-i))

ist doch auch nicht wirklich eine schöne Lösung, vorallem da doch praktisch alle CPUs solche Befehle direkt unterstüzen.

Mhm, in C/C++ gibt es solche Konstrukte, die praktisch von jedem Compiler zu ROR/ROL übersetzt/optimiert werden. Vielleicht funktioniert das bei Delphi auch?

[himitsu]

Als ich das letzte Mal nachsah, da war er nicht so schlau. :?

[OlafSt]

Mit einer winzigen Veränderung gehts auch in 64-Bit:

Delphi-Quellcode:

function ROL(Value: Cardinal; Count: Byte): Cardinal; assembler;  //Beachte die Direktive
asm
   ROL EAX, DL
end;

Cardinals, weil das ganze als unsigned-Rotate arbeitet.

[himitsu]

Sprünge sind aber ungünstig und inlining klappt bei Assembler nicht so gut.
Dann fehlt ja nur noch OSX (das dürfte aber mit dem Win64 übereinstimmen) und dann gibt es noch iOS, iOS64, Android, Linux usw.

[Dejan Vu]

Wozu braucht man eigentlich den 'Rotate' Operator so?

[Amateurprofi]

Zitat:

Zitat von himitsu (Beitrag 1277459)

Sprünge sind aber ungünstig und inlining klappt bei Assembler nicht so gut.

Gar nicht!

Aus der OH : "Für Routinen, die Assembler-Code enthalten, wird kein Inlining vorgenommen."

[himitsu]

Das ist wie das SHL/SHL, nur daß dort die Bits nicht ins Nichts rausgeschoben werden, sondern auf der anderen Seite wieder rein rutschen.

Wird meisten bei Verschlüsselungs-, Hash- und Prüfsummenfunktionen benutzt.

[Neutral General]

Hab auch mal etwas rumprobiert aber ich befürchte ohne calls kriegt mans nicht hin.
Vielleicht mit ganz brutalen Hacks aber sonst eher nicht.
Habe auch mal versucht einen eigenen Integer Typ zu definieren und rol/ror als class operator (für shl/shr) zu implementieren weil ich gehofft hatte er inlined class operatoren vielleicht, aber war leider auch nicht der Fall.

Dann musst du wohl die ganze Methode wo du rol/ror brauchst in Assembler schreiben :mrgreen:

[himitsu]

Meine MD5 und CRC-Codes in Assembler wollte ich halt abschaffen und als Pure-Pascal implementieren, um sie plattformunabhängig zu haben.

Im Windows könnte ich die geheimen MD5/SHA1-WinAPIs der advapi.dll verwenden.
Bei OSX, iOS, Android und im nächsten Jahrhundert wieder Linux müsste man mal schauen, ob die nicht vielleicht auch schon was haben, was man schön in einer plattformübergreifenden Klasse/Funktion kapseln kann.
Und wo es das nicht gibt oder es zu umständlich ist, dann eben meine Implementation.

Ansonsten hab ich überlegt, ob ich nicht stattdessen z.B. auf IdHashMessageDigest umsteige, wo ich aber den Overhead noch nicht kenn. (die EXEn sind ja eh schon viel zu groß, da kommt es auf ein paar mehr Byte auch nicht mehr drauf an)


[edit]
Wobei man mit APIs auch vorsichtig sein muß. :roll:
http://www.heise.de/tp/artikel/5/5274/1.html

[Memnarch]

Ich hab es bis heute nicht verstanden, warum es absolut gar kein Inline für AssemblerOnly routinen gibt.

[Neutral General]

Weils ziemlich "gefährlich" ist.
Du weißt in der inline-Methode nicht welche Register in der aufrufenden Methode noch gebraucht werden, du weißt nicht wie der Stack aussieht etc. Und Delphi weiß nicht was du da in Assembler geschrieben hast und schafft es dann einfach nicht dein Assemblercode in die entsprechenden Methoden einzubauen. Denn da wie schon gesagt der Code meistens nicht 1:1 in die aufrufende Methode passt (ohne irgendwas kaputt zu machen) müsste Delphi die Semantik deines Codes erkennen und deinen Ursprungscode dynamisch an die jeweilige Situation der aufrufenden Methode anpassen.

[Memnarch]

Zitat:

Zitat von Neutral General (Beitrag 1277678)

Weils ziemlich "gefährlich" ist.
Du weißt in der inline-Methode nicht welche Register in der aufrufenden Methode noch gebraucht werden, du weißt nicht wie der Stack aussieht etc. Und Delphi weiß nicht was du da in Assembler geschrieben hast und schafft es dann einfach nicht dein Assemblercode in die entsprechenden Methoden einzubauen. Denn da wie schon gesagt der Code meistens nicht 1:1 in die aufrufende Methode passt (ohne irgendwas kaputt zu machen) müsste Delphi die Semantik deines Codes erkennen und deinen Ursprungscode dynamisch an die jeweilige Situation der aufrufenden Methode anpassen.

Ich schätze das würde funktionieren, wenn man einen gewissen satz an restriktionen setzen würde.

Max 2 Paremeter + Result
Parameter und Result werden fest auf einen eigenen register gemapped (Deswegen auch nur support für 2 plus result)
Somit sind die parameter(+Result) auch nur in Mnemonics mit Register-Parametern zulässig.

Durch das strikte mapping des Input/Output sollte der compiler in der lage sein die Parameter der aufrufenden funktion vor dem inlined asm zu sichern bzw collisionen zu erkennen.

[himitsu]

Und dann kann Delphi nicht die "Variablen" verschieben, was dann eh kranken Code erzeugt (umkopieren der Variablen in Register/Stack), wenn es geinlined wird.

Siehe Beispiel in #1: Für EAX und DL werden die Parameter (übergebenen) Variablen ja nicht an den stellen ersetzt, sondern vorher dort reinkopiert und nachher das Result wieder zurück.

OK, man könnte das ja auch so schreiben, wenn Delphi nicht intelligent genug ist rauszubekommen was welcher Parameter ist.

Delphi-Quellcode:

function ROL(Value: Integer; Count: Byte): Integer; inline;
asm
  ROL &Value, &Count
end;

Aber nun sind ja Value und Result ja im selben Register und schon weiß Delphi nicht mehr wo das Result hin ist.

Delphi-Quellcode:

function ROL(Value: Integer; Count: Byte): Integer; inline;
asm
  MOV &Result, &Value
  ROL &Result, &Count
end;

Und schon hat man wieder einen blöden Code.

Zitat:

Du weißt in der inline-Methode nicht welche Register in der aufrufenden Methode noch gebraucht werden

Das weiß man auch in der Funktion nicht, aber es gibt ja Regeln welche Register man immer sichern/wiederherstellen muß.
Entweder es behandelt die Register während des Inline-Codes so, als wären sie wie beim CALL belegt oder es sichert (PUSH/POP) sich die entsprechenden Register.
Und da es ein SinglePassCompiler ist, müsste Delphi immer alles sichern, da es vorher noch nicht weiß welche Register in der Prozedur verwendet werden. [edit] halt nee, das wurde vorher kompiliert und man müsste es sich nur merken.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1277526)

Im Windows könnte ich die geheimen MD5/SHA1-WinAPIs der advapi.dll verwenden.

Die benutzen wir auch, ja. Da die Crypto-API gut dokumentiert ist, ist das auch sehr einfach zu implementieren. Die Header-Datei habe ich soweit nötig selbst übersetzt.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1277701)

Zitat:

Zitat von himitsu (Beitrag 1277526)

Im Windows könnte ich die geheimen MD5/SHA1-WinAPIs der advapi.dll verwenden.

Die benutzen wir auch, ja. Da die Crypto-API gut dokumentiert ist, ist das auch sehr einfach zu implementieren. Die Header-Datei habe ich soweit nötig selbst übersetzt.

Hab mir ja den Context als Record deklariert und darin als Record-Methoden direkt die API angebunden.
Der unsichtbare Self-Parameter passt super über den ersten Context-VAR-Parameter der API. :angel:

Aber da fehlt nun halt die OSX/iOS/Android-Implementation der Funktionen, drum wollte ich dort meinen alten Code als Pascal einbinden (war bisher in Win32-Assembler geschrieben),
außer jemand findet eine "kompatible" API in diesen Plattformen.


Oder ich schau eben, ob es nicht eine Alternative gibt, welche möglichst überall funktioniert. (z.B. die Indy, welche doch überall funktionieren/existieren?)

[Memnarch]

Zitat:

Zitat von himitsu (Beitrag 1277697)

Aber nun sind ja Value und Result ja im selben Register und schon weiß Delphi nicht mehr wo das Result hin ist.

Delphi-Quellcode:

function ROL(Value: Integer; Count: Byte): Integer; inline;
asm
  MOV &Result, &Value
  ROL &Result, &Count
end;

Und schon hat man wieder einen blöden Code.

Man könnte durch neue Postfixe bei den parametern dem Compiler mitteilen, dass ein Parameter sowohl als in als auch als out fungiert(out kanns nur einen geben, dann fällt das Result weg).

Sowas wie:

Delphi-Quellcode:

procedure ROL(InOut Value: Integer; Count: Byte);inline;
asm
  ROL &Value, &Count
end;

schon weiß der compiler wieder, wo der Hase lang läuft. Und festgelegten Output braucht man primär, wenn die inline funktion in einer expression benutzt wird.