Jan Bruns wrote:
> "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.

Es war aber nötig, ansonsten hätte man immer mit den 64 Bit Registern
arbeiten müssen, wenn man den Code nicht unnötig verlangsamen möchte.

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

Ich weiß nicht, was Du mit Integrationsdichte meinst.

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

Der Prozessor hat vielleicht 64 Register von denen mehrere den Wert von
rax zu einem bestimmten Zeitpunkt enthalten können. Nehmen wir z.B. so
einen Code:

mov eax, 1
push eax
mov eax, 2
push eax

Der Prozessor kann hier die beiden movs parallel ausführen (in
verschiende interne Register), da sie von nichts abhängen.

Würde jedoch "mov eax, 1" den oberen Teil von rax erhalten, dann gibt es
zwei Möglichkeiten:

1) Der "mov eax, 2" wird erst ausgeführt, wenn der finale Wert von rax
bekannt ist (dh. bis alle Anweisungen davor, die rax anfassen,
bearbeitet sind).
2) Der Prozessor teilt rax auf verschiedene interne Register auf. Falls
danach rax gelesen wird, muss der Prozessor die internen Register wieder
zusammenfassen.

Beides ist nicht schön.

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

Ich bin kein Prozessorhersteller, und ich kann nur die momentane
Situation reflektieren.

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

Nein. Dass ah usw. nicht mehr verwendet werden, hat zwar ähnliche
Ursachen, aber das meine ich nicht.

Ich meine z.B. sowas:

movzx eax, [byte1]
movzx ecx, [byte2]
cmp eax, ecx

statt:

mov al, [byte1]
mov cl, [byte2]
cmp al, cl

Ein "movzx eax, .." kann unabhängig davon ausgeführt werden, was in eax
steht. Bei "mov al, .." haben wir die Situation, die ich oben
beschrieben habe.

>
> Das hat vielleicht verschiedene Ursachen, aber einer davon ist
> sicherlich memory alignment.

Nein, das hat mit Alignment nichts zu tun. Byte-Zugriffe sind immer aligned.

--
Gruß,
Sebastian

"Sebastian Biallas":
> Jan Bruns wrote:
>> "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.

> Es war aber nötig, ansonsten hätte man immer mit den 64 Bit Registern
> arbeiten müssen, wenn man den Code nicht unnötig verlangsamen möchte.

Nee, komm, also Notwendigkeit ist wat anners.

Arbeitet man nicht ohnehin immer mit 64-Bit Registern?

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

> Ich weiß nicht, was Du mit Integrationsdichte meinst.

Damit habe ich die Transitoranzahl gemeint. Ist üblich.

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

> Der Prozessor hat vielleicht 64 Register von denen mehrere den Wert von
> rax zu einem bestimmten Zeitpunkt enthalten können. Nehmen wir z.B. so
> einen Code:
> [...]
> Der Prozessor kann hier die beiden movs parallel ausführen (in
> verschiende interne Register), da sie von nichts abhängen.

> Würde jedoch "mov eax, 1" den oberen Teil von rax erhalten, dann gibt es
> zwei Möglichkeiten:

Hier hast Du nun erstmal die Möglichkeit vergessen, daß man dann doch
durchaus auch movzx schreiben könnte, um exakt die obige Situation
zu konstruieren.

> 1) Der "mov eax, 2" wird erst ausgeführt, wenn der finale Wert von rax
> bekannt ist (dh. bis alle Anweisungen davor, die rax anfassen,
> bearbeitet sind).
> 2) Der Prozessor teilt rax auf verschiedene interne Register auf. Falls
> danach rax gelesen wird, muss der Prozessor die internen Register wieder
> zusammenfassen.

> Beides ist nicht schön.

Naja, das hattest Du ja schon geschrieben. Ist ja auch nett, wenn Du
versuchst, die aktuellen Gegebenheiten zu beschreiben.

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

> Ich bin kein Prozessorhersteller, und ich kann nur die momentane
> Situation reflektieren.

So wie du hier argumentierst wäre es aber doch ganz sinnig, wenn Du
wenigstens bezüglich dieses Details (zentrales execute auf "externem"
Registerspeicher) irgendwelche Zukunftserwartungen hättest.

Worauf willst Du sonst die Begriffe "notwendig, logisch, sinnvoll"
stützen?

>> Das hat vielleicht verschiedene Ursachen, aber einer davon ist
>> sicherlich memory alignment.

> Nein, das hat mit Alignment nichts zu tun. Byte-Zugriffe sind
> immer aligned.

Sehe ich anders, is aber echt egal.

gruss

Jan Bruns

Jan Bruns wrote:
> "Sebastian Biallas":
>> Jan Bruns wrote:
>>> "Sebastian Biallas":
>> Es war aber nötig, ansonsten hätte man immer mit den 64 Bit Registern
>> arbeiten müssen, wenn man den Code nicht unnötig verlangsamen möchte.
>
> Nee, komm, also Notwendigkeit ist wat anners.
>
> Arbeitet man nicht ohnehin immer mit 64-Bit Registern?

Da ein int üblicherweise noch 32 Bit groß ist, arbeitet man häufig noch
mit 32 Bit Registern.

>>> 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.
>
>> Ich weiß nicht, was Du mit Integrationsdichte meinst.
>
> Damit habe ich die Transitoranzahl gemeint. Ist üblich.

Ich verstehe trotzdem nicht, wie Du das Problem lösen willst, indem Du
da Transistoren hinterherwirfst.

>> Würde jedoch "mov eax, 1" den oberen Teil von rax erhalten, dann gibt es
>> zwei Möglichkeiten:
>
> Hier hast Du nun erstmal die Möglichkeit vergessen, daß man dann doch
> durchaus auch movzx schreiben könnte, um exakt die obige Situation
> zu konstruieren.

Also müsste man den Code mit movzx vollmachen.

>> Ich bin kein Prozessorhersteller, und ich kann nur die momentane
>> Situation reflektieren.
>
> So wie du hier argumentierst wäre es aber doch ganz sinnig, wenn Du
> wenigstens bezüglich dieses Details (zentrales execute auf "externem"
> Registerspeicher) irgendwelche Zukunftserwartungen hättest.

Dann beschreib doch mal, wie es besser gehen sollte.

>>> Das hat vielleicht verschiedene Ursachen, aber einer davon ist
>>> sicherlich memory alignment.
>
>> Nein, das hat mit Alignment nichts zu tun. Byte-Zugriffe sind
>> immer aligned.
>
> Sehe ich anders, is aber echt egal.

Wie definierst Du denn Aligment? Und warum soll movzx daran etwas ändern?

--
Gruß,
Sebastian

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


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

>>> Ich weiß nicht, was Du mit Integrationsdichte meinst.

>> Damit habe ich die Transitoranzahl gemeint. Ist üblich.

> Ich verstehe trotzdem nicht, wie Du das Problem lösen willst, indem Du
> da Transistoren hinterherwirfst.

Vielleicht so, wie es gemacht wird, wenn ich bspw. in 32-Bit Code
"and eax,ebx" schreibe. Wenn im gleichen Code irgendwo "and ax,bx"
steht, und genau das die Pipeline verwirrt, dann hat da doch wohl
höchstwahrscheinlich irgendwer keine Lust gehabt, sich um solche
Details zu kümmern.

Klar, in den Broschüren der Hersteller heisst "keine Lust gehabt"
dann auch gerne mal "technisch notwendig" (sorry, ich hatte in letzter
Zeit etwas viel mit GPUs zu tun, da sehen die Hersteller sowas noch
recht "locker").


>> So wie du hier argumentierst wäre es aber doch ganz sinnig, wenn Du
>> wenigstens bezüglich dieses Details (zentrales execute auf "externem"
>> Registerspeicher) irgendwelche Zukunftserwartungen hättest.

> Dann beschreib doch mal, wie es besser gehen sollte.

Von sollen hab' ich nix geschrieben.
Ich schrieb was von: könnte sein, daß das auch anders gut geht.
Weiß ich doch nicht. Bin kein CPU-Hersteller. Du auch nicht,
schreibst Du. Von daher kämen wir besser mit'nander aus,
wenn Du statt

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

besser sowas schriebest:

< Das gilt auch weiterhin. Allerdings gilt danach (rax&0xffffffff00000000)==0.
<
< Das soll für moderne CPUs aktuell technisch sinnvoll sein, weil dann...
< [Ausführung zum Thema zentralisierte Execute-Einheit und ihre Register].



Gruss

Jan Bruns

Jan Bruns wrote:
>
> Vielleicht so, wie es gemacht wird, wenn ich bspw. in 32-Bit Code
> "and eax,ebx" schreibe. Wenn im gleichen Code irgendwo "and ax,bx"
> steht, und genau das die Pipeline verwirrt, dann hat da doch wohl
> höchstwahrscheinlich irgendwer keine Lust gehabt, sich um solche
> Details zu kümmern.

Das ist natürlich möglich. Allerdings stehen Intel und AMD in
Konkurrenzkampf und keiner der beiden hat es geschafft das Problem in
soweit zu lösen, dass es "kein Problem" mehr ist.

> Klar, in den Broschüren der Hersteller heisst "keine Lust gehabt"
> dann auch gerne mal "technisch notwendig" (sorry, ich hatte in letzter
> Zeit etwas viel mit GPUs zu tun, da sehen die Hersteller sowas noch
> recht "locker").

Die ISA wurde halt so angelegt, dass der "Normalfall" möglich effizient
von der CPU behandelt werden kann. Dies halte ich grundsätzlich für
nachvollziehbar und sinnvoll.

>>> So wie du hier argumentierst wäre es aber doch ganz sinnig, wenn Du
>>> wenigstens bezüglich dieses Details (zentrales execute auf "externem"
>>> Registerspeicher) irgendwelche Zukunftserwartungen hättest.
>
>> Dann beschreib doch mal, wie es besser gehen sollte.
>
> Von sollen hab' ich nix geschrieben.
> Ich schrieb was von: könnte sein, daß das auch anders gut geht.

Natürlich kann das sein. Da aber offenbar keiner eine Lösung dafür
kennt, hat man das Problem des partiellen Registerzugriffs bei x86_64
direkt vermieden (wie es z.B. PowerPC schon vor Jahrzehnten vorgemacht hat).

> Weiß ich doch nicht. Bin kein CPU-Hersteller. Du auch nicht,
> schreibst Du. Von daher kämen wir besser mit'nander aus,
> wenn Du statt
>
> | 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.
>
> besser sowas schriebest:
>
> < Das gilt auch weiterhin. Allerdings gilt danach (rax&0xffffffff00000000)==0.
> <
> < Das soll für moderne CPUs aktuell technisch sinnvoll sein, weil dann...
> < [Ausführung zum Thema zentralisierte Execute-Einheit und ihre Register].

Warum? Wenn man partiellen Registerzugriff erlaubt, dann muss die CPU
sich auch damit rumschlagen (das sollte offensichtlich sein). Und dass
es für heutige Prozessoren schlecht ist, kann man aus den Intel und AMD
Dokumentationen entnehmen.

--
Gruß,
Sebastian

hi, hipo!

sieht ganz nach einem big-endian zu little-endian mit shifting
algorithmus
aus.
kennst du den damals dafuer entstandenen befehl bswap ??
vielleicht kannst du damit eleganteren code schreiben.
nur kenn ich leider die neuen 64bit register regeln nicht so genau.
aber vielleicht geht ja dies:
BSWAP rax
ROL/ROR rax,32

gruss florian.

Florian Liebig wrote:

rax = |a b c d e f g h|
> BSWAP rax
rax = |h g f e d c b a|
> ROL/ROR rax,32
rax = |d c b a h g f e|

Der OP wollte aber rax = |c d a b g h e f| erreichen...

--
Gruß,
Sebastian

hi sebastian!

na klar, wie du sagst.
ich habe mich in seinem post etwas verlesen.

Hipo wrote:
> |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|

Wie auch immer die 64bit-Dinger heissen mögen:

A = B [abcdefgh]
A linksrotate 16 bit [cdefghab]
B rechtsrotate 16 bit [ghabcdef]
A and ffff0000ffff0000 [cd--gh--]
B and 0000ffff0000ffff [--ab--ef]
A or B [cdabghef]

Schneller kanns nicht wirklich gehen.

Freundliche Grüsse
//Herbert Glarner

--
http://herbert.wikispaces.com