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 (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 von himitsu:

Aber vorallem in Bezug auf Multiplattform macht sich Assembler eh nicht so gut
und sowas wie (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 von himitsu:

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

[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ß.
http://www.heise.de/tp/artikel/5/5274/1.html