Hi.
Ich hab noch ein Problem, auf dessen Lösung ich einfachnicht komme.
Ich habe 8 Bytes in einem Register, z.B. RAX. Sie sind wie folgt
angeordnet:

|a b c d e f g h|

Mein Ziel ist es, das Register am Schluss so ausehen zu lassen:

|c d a b g h e f|

Ich muss also die hohen und die niedrigen Byte voneinander unabhängig
rotieren.
Meine Lösung wäre:

ROTL EAX, 16
ROTL RAX, 32
ROTL EAX, 16
ROTL RAX, 32

Ich finde das nicht elegant, und sicherlich nicht sher effizient, da ich
diese Berechnung sehr oft durchlaufen muss.

Hat vielleicht jemand einen Trick auf Lager, der diese Operation
effizienter erledigen kann?

mfg, Hipo

Hipo wrote:
> Hi.
> Ich hab noch ein Problem, auf dessen Lösung ich einfachnicht komme.
> Ich habe 8 Bytes in einem Register, z.B. RAX. Sie sind wie folgt
> angeordnet:
>
> |a b c d e f g h|
>
> Mein Ziel ist es, das Register am Schluss so ausehen zu lassen:
>
> |c d a b g h e f|
>
> Ich muss also die hohen und die niedrigen Byte voneinander unabhängig
> rotieren.
> Meine Lösung wäre:
>
> ROTL EAX, 16

Das löscht den oberen Teil von RAX. Hast Du das überhaupt ausprobiert?

> Hat vielleicht jemand einen Trick auf Lager, der diese Operation
> effizienter erledigen kann?

pshufw

Ansonsten würde ich den Wert in EDX:EAX speichern. Was versuchst Du da
eigentlich zu erreichen?

--
Gruß,
Sebastian

Sebastian Biallas schrieb:
> Hipo wrote:
>> Hi.
>> Ich hab noch ein Problem, auf dessen Lösung ich einfachnicht komme.
>> Ich habe 8 Bytes in einem Register, z.B. RAX. Sie sind wie folgt
>> angeordnet:
>>
>> |a b c d e f g h|
>>
>> Mein Ziel ist es, das Register am Schluss so ausehen zu lassen:
>>
>> |c d a b g h e f|
>>
>> Ich muss also die hohen und die niedrigen Byte voneinander unabhängig
>> rotieren.
>> Meine Lösung wäre:
>>
>> ROTL EAX, 16
>
> Das löscht den oberen Teil von RAX. Hast Du das überhaupt ausprobiert?

Ich bin noch in der Planungsphase. Ich hätte es gern ausprobiert, aber
VS 2005 für x64 unterstützt keinen inline assembler. Bisher hatte ich
noch keine Zeit reinen Assembler code zu schreiben, wobei ich mich da
erst einlesen muss, da ich es noch nicht verwerendet hab.

>> Hat vielleicht jemand einen Trick auf Lager, der diese Operation
>> effizienter erledigen kann?
>
> pshufw

Kannst du mir aus Erfahrung sagen, wie sehr die Performance unter
Datentransfers zwischen XMM und GPR Register leidet. Ich habe
diesbezüglich bereits einige Warnungen erhalten.
>
> Ansonsten würde ich den Wert in EDX:EAX speichern. Was versuchst Du da
> eigentlich zu erreichen?

Für einen Teil eines Verschlüsselungsalgorithmus muss ich oben
beschriebene Permutationen durchführen.

mfg, Hipo

Hipo wrote:
>> pshufw
>
> Kannst du mir aus Erfahrung sagen, wie sehr die Performance unter
> Datentransfers zwischen XMM und GPR Register leidet. Ich habe
> diesbezüglich bereits einige Warnungen erhalten.

Wahrscheinlich zu recht. Besser ist es, alles mit MMX/SSE zu machen.

--
Gruß,
Sebastian

"Hipo":
> Ich hab noch ein Problem, auf dessen Lösung ich einfachnicht komme.
> Ich habe 8 Bytes in einem Register, z.B. RAX. Sie sind wie folgt
> angeordnet:

> |a b c d e f g h|

> Mein Ziel ist es, das Register am Schluss so ausehen zu lassen:
>
> |c d a b g h e f|


Also mal in 32-Bit Schreibweise (für 64 Bit lässt sich das sicherlich
einfach erweitern):

; "eax=a,b,c,d -> eax=c,d,a,b"
mov ebx,eax
and eax,$FFFF0000
and ebx,$0000FFFF
shr eax,16
shl ebx,16
or eax,ebx

oder einfach:

; "eax=a,b,c,d -> eax=c,d,a,b"
rol eax,16

letzteres is so natürlich nicht auf 64-Bit übertragbar.

Gruss

Jan Bruns

"Sebastian Biallas":
> Hipo wrote:

>> ROTL EAX, 16

> Das löscht den oberen Teil von RAX. Hast Du das überhaupt ausprobiert?

Wie heisst denn in dieser neumodischen 64-Bit Technik der Befehl
für Rotation? Gab doch schon immer rot und shift, mit und ohne Carry.

Grussauch

Jan Bruns wrote:
> "Sebastian Biallas":
>> Hipo wrote:
>
>>> ROTL EAX, 16
>
>> Das löscht den oberen Teil von RAX. Hast Du das überhaupt ausprobiert?
>
> Wie heisst denn in dieser neumodischen 64-Bit Technik der Befehl
> für Rotation?

Weiterhin rol bzw. ror usw, das da oben ist wahrscheinlich ein
Tippfehler. Es hat sich von 32->64 am Befehlssatz eigentlich kaum was
geändert. Ein paar Befehle sind rausgeflogen, hinzu kam eigentlich nur
movsxd, ein neuer Adressierungsmodus (IP-relativ), ein bissl SSE-Kram
und esoterisches. Und man hat halt doppelt so viele Register.

Man sollte halt nur wissen, dass beim Zugriff auf ein Teilregister immer
die oberen 32 Bit gelöscht werden.

Die Aufgabe des OP ist für ein 64 Bit Register wohl nicht so einfach,
deshalb mein Vorschlag, auf zwei 32 Bit Register auszuweichen.

--
Gruß,
Sebastian

"Sebastian Biallas":

> Man sollte halt nur wissen, dass beim Zugriff auf ein Teilregister immer
> die oberen 32 Bit gelöscht werden.

Das muss ich bei Gelegenheit mal nachschlagen...

Ist ja bisher auch anders gewesen:

mov eax,$12345678
mov ax, $5678
mov al, $78

-> eax = $12345678

Jan Bruns wrote:
> "Sebastian Biallas":
>
>> Man sollte halt nur wissen, dass beim Zugriff auf ein Teilregister immer
>> die oberen 32 Bit gelöscht werden.
>
> Das muss ich bei Gelegenheit mal nachschlagen...
>
> Ist ja bisher auch anders gewesen:
>
> mov eax,$12345678
> mov ax, $5678
> mov al, $78
>
> -> eax = $12345678

Das gilt auch weiterhin. Allerdings gilt danach (rax&0xffffffff00000000)==0.

Das ist aber auch sinnvoll so. Obiges Verhalten war vor 20 Jahren
vielleicht noch verständlich, ist aber für heutige Prozessoren sehr
schlecht, weil man mit den partial register stalls umgehen muss.

Bei dem "mov al, $78" muss der Prozessor entweder auf den Wert von rax
warten, bis er den Befehl zuende ausführen kann, oder er zerteilt das
Register und muss es später u.U. wieder kompliziert zusammenführen. Ein
"mov eax, $78" hingegen kann er unabhängig von dem vorigen Wert von rax
ausführen.

Schau Dir mal Code vom einem aktuellen Compiler an, der mit Bytes
handtiert (z.B. Stringverarbeitung). Der ist voll von scheinbar
unnötigen movzx/movsx. Das macht man halt, um dem Prozessor Arbeit
abzunehmen.

--
Gruß,
Sebastian

"Sebastian Biallas":
> Jan Bruns wrote:
>> "Sebastian Biallas":

>> mov eax,$12345678
>> mov ax, $5678
>> mov al, $78

>> -> eax = $12345678

> Das gilt auch weiterhin. Allerdings gilt danach (rax&0xffffffff00000000)==0.

Naja, interessiert mich momentan nicht hinreichend, um das nachzuschlagen.
Jedenfalls: Ziemlich inkonsequent sieht das aus.

> Das ist aber auch sinnvoll so. Obiges Verhalten war vor 20 Jahren
> vielleicht noch verständlich, ist aber für heutige Prozessoren sehr
> schlecht, weil man mit den partial register stalls umgehen muss.

Also ich kann nun nicht gerade behaupten, über die pipelinetechnsichen
Hintergründe bzgl. partieller Register genauestens informiert zu sein.
Klingt für mich eigentlich eher nach Integrationsdichte, als nach
echten Engpässen.

> Bei dem "mov al, $78" muss der Prozessor entweder auf den Wert von rax
> warten, bis er den Befehl zuende ausführen kann, oder er zerteilt das
> Register und muss es später u.U. wieder kompliziert zusammenführen. Ein
> "mov eax, $78" hingegen kann er unabhängig von dem vorigen Wert von rax
> ausführen.

Der Prozessor muss auf rax warten? Wo ist denn rax implementiert?

Du meinst wahrscheinlich einfach irgendeine zentrale Verarbeitungseinheit
in der CPU. Dazu ist einfach mal festzustellen, daß es neben schematischen
Trennung von Befehlausführung und Registersatz auch völlig andere
Implementationen denkbar sind. Bspw. könnte man für jedes Register
eine eigene Ausführungseinheit vorsehen, um dann nur noch Datentransfers
zwischen Registern bzw. externem Speicher zentralisiert organisieren zu
müssen. In Anbetracht der "aktuellen" Problematik weiterhin schnell
steigende(r) Integrationsumfang/dichte bei geringem Taktratenzuwachs
vielleicht nichtmal eine völlig absurde Vorgehensweise.

> Schau Dir mal Code vom einem aktuellen Compiler an, der mit Bytes
> handtiert (z.B. Stringverarbeitung). Der ist voll von scheinbar
> unnötigen movzx/movsx. Das macht man halt, um dem Prozessor Arbeit
> abzunehmen.

Also Du meinst den Zusammenhang, daß obwohl nur bspw. vereinzelte
Bytes zu verarbeiten sind (von denen mehrere in einem Register
gespeichert werden könnten), in der Praxis trotzdem regelmässig nur
eine Dateneinheit pro Register verwendet wird, und dabei denn auch
unnötig häufig die nicht verwendeten Anteile explizit überschrieben
werden?

Das hat vielleicht verschiedene Ursachen, aber einer davon ist
sicherlich memory alignment. Wenn es dagegen darum geht, bspw.
den Befehl "mov al,bl" CPU-optimiert zu schreiben, kam da
bislang regelmässig sowas wie "mov eax,ebx" heraus, wenn die
oberen Anteile von ebx eh' trivial sind, obwohl die Formulierung
"movzx eax,bl" sicherlich einfacher ist.

Gruss

Jan Bruns