PNI: Intel emuliert 3DNow! [Archiv]

zeckensack

2004-02-09, 03:01:59

"Prescott New Instructions Software Developer's Guide" (PDF) (http://cache-www.intel.com/cd/00/00/05/15/51549_pniwithopcodes.pdf)

"3DNow Technology Manual" (PDF) (http://www.amd.com/K6/k6docs/pdf/21928.pdf)
Athlon Extensions für 3DNow! (PDF) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22466.pdf)

Intel baut in SSE2 nun die schönen Sachen ein, die auf dem Athlon schon immer etwas einfacher waren :)
Ich werde ASM-Code-Beispiele bringen. Dabei ist zu beachten, dass SSE eine schlechtere Granularität hat, weil eben vier (32bit-)Werte pro Register gespeichert werden können, und nicht nur zwei. Ein paar der Probleme, die PNI hier löst, entstehen dadurch erst. Durch die geringe Granularität ist bei 3DNow der Bedarf an Shuffles einfach viel geringer.
Andererseits bedarf es auch jeweils zwei Operationen, um 128 Bit Daten zu laden/zu bearbeiten, und nicht nur einer, wie bei SSE.

Ich fand's trotzdem fast schon erschreckend :D

1)FISTTP
Konvertiert eine FP-Zahl nach Integer, und ignoriert dabei den aktuellen Rundungs-Modus der FPU. Es wird immer Truncation verwendet. "Normaler" x87-Code muss zuerst immer die FPU in diesen Rundungsmodus umschalten, und nach der Konvertierung den alten Modus wiederherstellen.

;x87
SUB ESP,4
FCLEX
FSTCW word [ESP]
MOV AX,[ESP]
OR AX,0xC00
MOV [ESP+2],AX
FLDCW word [ESP+2]
FLD dword [in]
FISTP dword [out]
FLDCW word [ESP]
ADD ESP,4

;x87/PNI
FLD dword [in]
FISTTP dword [out]

;3DNow!
MOVD mm0,[in]
PF2ID mm0,mm0
MOVD [out],mm0

2a)MOVSHDUP
Vereinfachter Shuffle/Move

;SSE
MOVUPS xmm0,[in]
SHUFPS xmm0,xmm0,240
MOVUPS [out],xmm0

;SSE/PNI
MOVUPS xmm0,[in]
MOVSHDUP xmm0,xmm0
MOVUPS [out],xmm0

;3DNow!
MOVD mm0,[in+4]
MOVD mm1,[in+12]
PUNPCKHDQ mm0,mm0
PUNPCKHDQ mm1,mm1
MOVQ [out],mm0
MOVQ [out+8],mm1

2b)MOVSHDUP
Quasi das gleiche in grün.

2c)MOVDDUP

Verdoppelt einen Wert in zwei Register-Hälften
;SSE2
MOVLPD xmm0,[in]
MOVHPD xmm0,[in]

;SSE2/PNI
MOVDDUP xmm0,[in]

;3DNow - 64Bit-Werte können nicht sinnvoll verarbeitet werden
;32 Bit-Variante (ausser Konkurrenz)
MOVD mm0,dword [in]
PUNPCKLDQ mm0,mm0

3)LDDQU
Komplett sinnlose Instruktion. Kann 128-Bit-Werte von "unaligned"-Addressen laden. Das konnte allerdings auch der P3 schon.
;SSE/4x32 Bit
MOVUPS xmm0,[in]

;SSE2/2x64 Bit
MOVUPD xmm0,[in]

;SSE2/PNI/2x64 Bit
LDDQU xmm0,[in]

;3DNow!/4x32 Bit
MOVQ mm0,[in]
MOVQ mm1,[in+8]

So, jetzt kommt's.

4a)ADDSUBPS
Gemischte Addition/Subtraktion von Vektor-Elementen
;SSE
MOVUPS xmm0,[in1]
MOVUPS xmm1,[in2]
XORPS xmm2,xmm2
MOVSS xmm2,[in2]
MOVHPS xmm2,[in2+8]
SHUFPS xmm2,xmm2,100
SUBPS xmm1,xmm2
SUBPS xmm1,xmm2
ADDPS xmm0,xmm1
MOVUPS [out],xmm0

;SSE/PNI
MOVUPS xmm0,[in1]
ADDSUBPS xmm0,[in2]
MOVUPS [out],xmm0

;3DNow!+
MOVQ mm0,[in1]
PFPNACC mm0,[in2]
MOVQ mm1,[in1+8]
PFPNACC mm1,[in2+8]
MOVQ [out],mm0
MOVQ [out],mm1

4b)ADDSUBPD
Dito, nur für 64 Bit-Operanden.
;SSE2
MOVUPD xmm0,[in1]
XORPD xmm1,xmm1
MOVHPD xmm1,[in2]
ADDPD xmm1,xmm0
SUBPD xmm1,[in2]
SUBPD xmm0,xmm1
MOVUPD [out],xmm0

;SSE2/PNI
MOVUPD xmm0,[in1]
MOVUPD xmm1,[in2]
ADDSUBPD xmm0,xmm1
MOVUPD [out],xmm0

;3DNow! - nicht möglich da 64Bit-Operanden

Fortsetzung im nächsten Posting

zeckensack

2004-02-09, 03:16:56

5a)HADDPS
Verschränkung und Addition
;SSE
MOVUPS xmm0,[in1]
MOVUPS xmm1,[in2]
MOVAPS xmm2,xmm0
SHUFPS xmm2,xmm1,136
SHUFPS xmm0,xmm1,221
ADDPS xmm0,xmm2
MOVUPS [out],xmm0

;SSE/PNI
MOVUPS xmm0,[in1]
MOVUPS xmm1,[in2]
HADDPS xmm0,xmm1
MOVUPS [out],xmm0

;3DNow!
MOVQ mm0,[in1]
PFACC mm0,[in1+8]
MOVQ mm1,[in2]
PFACC mm1,[in2+8]
MOVQ [out],mm0
MOVQ [out+8],mm1

5b)HSUBPS
Dito, nur mit Subtraktion. Ersetze "ADDPS" durch "SUBPS" und "PFACC" durch "PFNACC"

5c)HADDPD
Wie HADDPS, nur mit 2x64 Bit statt 4x32 Bit. Mit 3DNow nicht möglich

5d)HSUBPD
Das müsst ihr selbst erraten :)

Lokadamus

2004-02-09, 03:48:02

mmm...

Gut, ich rate:
HSUBPD = Subtraktion, nur mit 2x64 Bit statt 4x32 Bit. Mit 3DNow nicht möglich.
Richtig geraten :???: ...

Gast

2004-02-09, 09:58:55

Ist es wahr???
Intel hat es endlich mal gerallt, das die Kompatibilität gefragt ist! Sie haben wohl ihren stolz endlich über Bord geworfen!
Nunja wenn man 64 Bit kopiert, kann man auch zugeben das 3dnow doch Vorteile hat, und macht es nicht ständig nieder, sondern integriert es endlich.

Hmm oder hat Amd die 64 Bit Extension an 3dnow gebunden hihihi :)

Für proger ist so´n Duron ne feine Sache;)

BlackBirdSR

2004-02-09, 10:24:39

Dumme Sache nur..

wer optimiert für 3dnow? wer für SSE/PNI?
Am Ende bekommt man als Prescott-Nutzer die neuen Befehle, und sie werden wohl auch genutzt, als K8 Nutzer schaut man in die Röhre, da 3dnow nicht berücksichtigt wurde.

komm ich mir jetzt verarscht vor, oder verstehe ich das falsch?

zeckensack

2004-02-09, 14:49:51

Original geschrieben von Gast
Ist es wahr???
Intel hat es endlich mal gerallt, das die Kompatibilität gefragt ist! Sie haben wohl ihren stolz endlich über Bord geworfen!
Nunja wenn man 64 Bit kopiert, kann man auch zugeben das 3dnow doch Vorteile hat, und macht es nicht ständig nieder, sondern integriert es endlich.Nein, das natürlich nicht.
Der Prescott kann keinen 3DNow-Code ausführen. Er erweitert lediglich SSE2 um horizontale Instruktionen. Der Grund für den irreführenden Thread-Titel war, dass AMD diese horizontalen Operationen schon in 3DNow eingebaut hatte. Man könnte sagen, die Notwendigkeit für diese Operationen wurde bei AMD früher erkannt.

Hmm oder hat Amd die 64 Bit Extension an 3dnow gebunden hihihi :)AFAIK nicht. Leider wird auch das 64Bit-Windows XP 3DNow nicht mehr unterstützen (und gleichzeitig auch die x87-FPU und Teile von SSE1 über Bord werfen). Einige bejubeln das als "modern", nur mir will sich der dadurch entstehende Mehrwert nicht ganz erschliessen.
Für proger ist so´n Duron ne feine Sache;) Das gilt nicht mehr uneingeschränkt. In der frühen P4-Ära waren Morgan-Durons und AthlonXPs IMO die interessantesten Entwicklerplattformen, weil man eben alle wichtigen Codepfade (x87, 3DNow für K6-2 und Athlon, SSE für P3, P4 und Athlon XP) auf einer Maschine schreiben und testen konnte.

Momentan würde ich den K8 vorziehen, da dieser eben SSE2 beherrscht, und das heutzutage zum guten Ton gehört.

Demirug

2004-02-09, 14:58:25

Original geschrieben von BlackBirdSR
Dumme Sache nur..

wer optimiert für 3dnow? wer für SSE/PNI?
Am Ende bekommt man als Prescott-Nutzer die neuen Befehle, und sie werden wohl auch genutzt, als K8 Nutzer schaut man in die Röhre, da 3dnow nicht berücksichtigt wurde.

komm ich mir jetzt verarscht vor, oder verstehe ich das falsch?

Das alte Problem. Ist doch aber das gleiche mit der ganzen 32Bit Software welche von den zusätzlichen Registern des K8 auch nicht profitieren kann.

Das einzige was da wirklich hielft ist die Endstufe des Compilers auf den Zielrechner zu verlagern.

zeckensack

2004-02-09, 15:16:27

Original geschrieben von BlackBirdSR
Dumme Sache nur..

wer optimiert für 3dnow? wer für SSE/PNI?Die wenigsten Programmierer schreiben überhaupt noch ASM-Code selbst. Viel öfter wird zu fertigen Vektor-Libraries, und dem Intel-Compiler gegriffen. Ersteres ist relativ herstellerneutral (wobei die offiziellen Intel-Libraries die besseren sein sollen, kA), letzteres erzeugt natürlich nur SSE-Optimierungen.

Am Ende bekommt man als Prescott-Nutzer die neuen Befehle, und sie werden wohl auch genutzt, als K8 Nutzer schaut man in die Röhre, da 3dnow nicht berücksichtigt wurde.

komm ich mir jetzt verarscht vor, oder verstehe ich das falsch? Das ist der Lauf der Dinge. SSE haftete von Anfang an a)der "ist von Intel, muss gut sein"-Bonus an, b)wurde 3DNow öfter mal nachgesagt, es wäre für "wissenschaftliche Anwendungen" ungeeignet, was natürlich nichts weiter als FUD ist. Man muss aber auch an die Marktverhältnisse denken. Es ist irgendwo logisch, dass sich die Software-Industrie auf SSE eingeschossen hat und 3DNow auf der Strecke blieb.
_____________________________

Ich will noch kurz was zu den Anwendugsfällen von PNI nachtragen.
1)FISTTP
"Truncation" ist der von ISO-C/ISO-C++ geforderte Rundungsmodus für Float->Int-Konvertierungen. "Round to nearest even" ist dagegen der "beste" Rundungsmodus, weil er bei 'normaler' Arithmetik die geringsten Fehler produziert.

Code, der viel von Float nach Integer wandelt, muss also oft nach "truncation" und zurück umschalten, was für die Hardware relativ teuer ist (FSTCW/FLDCW sind iA über Microcode gelöst, und legen die FPU für viele Takte komplett lahm).

FISTTP ist also eine Hardware-Optimierung für C. Feine Sache, IMO.

4)ADDSUBPS/ADDSUBPD
... sind wunderbar, wenn man mit komplexen Zahlen arbeitet. Ich zitiere mal das Athlon-Optimierungs-Manual von AMD

"Complex numbers have a “real” part and an “imaginary” part.
Multiplying complex numbers (ex. 3 + 4i) is an integral part of
many algorithms such as Discrete Fourier Transform (DFT) and
complex FIR filters. Complex number multiplication is shown
below:
(src0.real + src0.imag) * (src1.real + src1.imag) = result
result = (result.real + result.imag)
result.real = src0.real*src1.real - src0.imag*src1.imag
result.imag = src0.real*src1.imag + src0.imag*src1.real

Example 1:
(1+2i) * (3+4i) => result.real + result.imag
result.real = 1*3 - 2*4 = -5
result.imag = 1*4i + 2i*3 = 10i
result = -5 +10i

Assuming that complex numbers are represented as two
element vectors [v.real, v.imag], one can see the need for
swapping the elements of src1 to perform the multiplies for
result.imag, and the need for a mixed positive/negative
accumulation to complete the parallel computation of
result.real and result.imag."

5)HADDPS
Ist insbesondere für Skalarprodukte geeignet. Aus Skalarprodukten kann man Matrix*Vektor- und Matrix*Matrix-Multiplikation zusammensetzen, also ist das eine ziemlich wichtige Fähigkeit.

_________________________
Insgesamt halte ich PNI für eine sinnvolle Erweiterung von SSE/2. Auch wenn es nur sehr wenige neue Instruktionen sind, so sind sie doch wirklich nützlich.
Auf der anderen Seite wäre es natürlich noch besser gewesen, wenn diese Instruktionen schon in SSE2 enthalten gewesen wären. Dass die Funktionalität nützlich ist, war IMO schon früher abzusehen (bzw bekannt, in Hinblick auf die Existenz von 3DNow). SSE/2 wird erst durch PNI wirklich vollständig.

Börk

2004-02-09, 15:24:39

Original geschrieben von Demirug
Das einzige was da wirklich hielft ist die Endstufe des Compilers auf den Zielrechner zu verlagern.
Das kostet dann aber wieder Prozessorleistung. Man siehe Java...

Demirug

2004-02-09, 15:28:10

Original geschrieben von burk23
Das kostet dann aber wieder Prozessorleistung. Man siehe Java...

Eimal beim Anlauf oder Installieren. Ist durchaus verschmerzbar wenn es danach schneller läuft. Java ist da nicht unbedingt ein gutes Beispiel weil Java ursprünglich als Bytecode zum interpretieren gedacht war.

MegaManX4

2004-02-09, 17:42:20

Original geschrieben von zeckensack
AFAIK nicht. Leider wird auch das 64Bit-Windows XP 3DNow nicht mehr unterstützen (und gleichzeitig auch die x87-FPU und Teile von SSE1 über Bord werfen). Einige bejubeln das als "modern", nur mir will sich der dadurch entstehende Mehrwert nicht ganz erschliessen.

Wie soll ich das denn verstehen? Kann AMD bei den 64'ern deren FPU's nicht mehr nutzen? Würde da nicht auch die Kompatibilität zu so ziemlich jeder x86 Software drunter leiden?

zeckensack

2004-02-09, 17:59:37

Original geschrieben von MegaManX4
Wie soll ich das denn verstehen? Kann AMD bei den 64'ern deren FPU's nicht mehr nutzen? Dank Multitasking kann das OS ja jederzeit einen Prozess stoppen und einen anderen fortsetzen. Bei diesem Übergang müssen zwingend die Registerinhalte gesichert werden, weil der gestoppte Thread sonst eben zufällige, bzw für ihn ganz falsche Daten vorfinden würde, wenn er irgendwann später wieder weiterarbeiten darf. Der 'in der Zwischenzeit' ausgeführte Prozess kann diese Register ja verändert haben. Die kompletten Register werden also für jeden Thread am Ende der Zeitscheibe gespeichert, und unmittelbar bei Beginn der nächsten Zeitscheibe wiederhergestellt. Auf die Weise merken die Applikationen nichts vom Multitasking, sie müssen darauf keine Rücksicht nehmen.

Windows XP für AMD64 sichert nun beim Taskswitch die FPU-Register nicht mehr. Das bedeutet, dass man die FPU (und MMX, weil dieses die FPU-Register mitnutzt) nicht mehr sinnvoll benutzen kann. Man würde mit dem ständigen Risiko leben, plötzlich nur noch Datenmüll in den Registern zu haben.

Ich persönlich halte das für eine dumme Idee. Die Befürworter sagen "x87/MMX/3DNow! braucht doch eh keiner mehr, weil wir SSE2 haben. Also weg damit". Das halte ich für keine schlüssige Argumentation, weil dadurch nunmal auch nichts besser wird. Der K8 kann x87/MMX/3DNow!-Code ausführen, und es bringt keinen Gewinn, ihm das durch künstliche Hirnschäden im OS zu verbieten.

Und es kommt noch dümmer: für 32Bit-Threads werden die x87-Register dann doch wieder gesichert. Die 32Bit-Kompatibilität ist also eigentlich nicht gefährdet. Dadurch dürfen auch zukünftige AMD64-kompatible Prozessoren die x87-Fähigkeit nicht aufgeben, denn sie wird für den 32Bit-Kompatibilitätsmodus weiterhin gebraucht. Das ganze ist ein ziemlicher Eiertanz ohne erkennbaren Nutzen.

MegaManX4

2004-02-09, 18:20:43

Original geschrieben von zeckensack
Dank Multitasking kann das OS ja jederzeit einen Prozess stoppen und einen anderen fortsetzen. Bei diesem Übergang müssen zwingend die Registerinhalte gesichert werden, weil der gestoppte Thread sonst eben zufällige, bzw für ihn ganz falsche Daten vorfinden würde, wenn er irgendwann später wieder weiterarbeiten darf. Der 'in der Zwischenzeit' ausgeführte Prozess kann diese Register ja verändert haben. Die kompletten Register werden also für jeden Thread am Ende der Zeitscheibe gespeichert, und unmittelbar bei Beginn der nächsten Zeitscheibe wiederhergestellt. Auf die Weise merken die Applikationen nichts vom Multitasking, sie müssen darauf keine Rücksicht nehmen.

Windows XP für AMD64 sichert nun beim Taskswitch die FPU-Register nicht mehr. Das bedeutet, dass man die FPU (und MMX, weil dieses die FPU-Register mitnutzt) nicht mehr sinnvoll benutzen kann. Man würde mit dem ständigen Risiko leben, plötzlich nur noch Datenmüll in den Registern zu haben.

Ich persönlich halte das für eine dumme Idee. Die Befürworter sagen "x87/MMX/3DNow! braucht doch eh keiner mehr, weil wir SSE2 haben. Also weg damit". Das halte ich für keine schlüssige Argumentation, weil dadurch nunmal auch nichts besser wird. Der K8 kann x87/MMX/3DNow!-Code ausführen, und es bringt keinen Gewinn, ihm das durch künstliche Hirnschäden im OS zu verbieten.

Und es kommt noch dümmer: für 32Bit-Threads werden die x87-Register dann doch wieder gesichert. Die 32Bit-Kompatibilität ist also eigentlich nicht gefährdet. Dadurch dürfen auch zukünftige AMD64-kompatible Prozessoren die x87-Fähigkeit nicht aufgeben, denn sie wird für den 32Bit-Kompatibilitätsmodus weiterhin gebraucht. Das ganze ist ein ziemlicher Eiertanz ohne erkennbaren Nutzen.

Danke für die Erklärung. Nur kann ich mir immer noch nicht ganz vorstellen warum AMD da mitmachen sollte. Folgt man deiner Erklärung wären die FPU Einheiten im 64bit Modus von Windows quasi nutzlos da= kein potentielles Multitasking mehr. Zumal die Athlon 64 Linie beim SSE2 Speed den Pentiums (oder Pentien?) doch unterlegen ist.

Ehrlich gesagt lese ich das heute auch zum ersten mal. Hast du einige Quellen dafür?

zeckensack

2004-02-09, 18:35:35

Original geschrieben von MegaManX4
Danke für die Erklärung. Nur kann ich mir immer noch nicht ganz vorstellen warum AMD da mitmachen sollte. Folgt man deiner Erklärung wären die FPU Einheiten im 64bit Modus von Windows quasi nutzlos da= kein potentielles Multitasking mehr. Zumal die Athlon 64 Linie beim SSE2 Speed den Pentiums (oder Pentien?) doch unterlegen ist.

Ehrlich gesagt lese ich das heute auch zum ersten mal. Hast du einige Quellen dafür? Ich hab mal kurz gegoogelt (http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&q=Windows+64+bit+x87+registers&btnG=Google+Search) :freak:

AMD sagt ... (PDF) (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_Porting_Win_DD_to_AMD64_Sept24.pdf):
Convert media instructions to SSE/SSE2 Instructions
Microsoft Windows for AMD64 will not context switch x87, 3DNow!, MMX for 64-bit native threads. This code may be converted to SSE/SSE2 through the use of intrinsic functions.
(Seite 7)

MegaManX4

2004-02-09, 18:40:29

Muh-sagt-die-Kuh

2004-02-09, 18:50:47

Original geschrieben von zeckensack

1)FISTTP
"Truncation" ist der von ISO-C/ISO-C++ geforderte Rundungsmodus für Float->Int-Konvertierungen. "Round to nearest even" ist dagegen der "beste" Rundungsmodus, weil er bei 'normaler' Arithmetik die geringsten Fehler produziert.

Code, der viel von Float nach Integer wandelt, muss also oft nach "truncation" und zurück umschalten, was für die Hardware relativ teuer ist (FSTCW/FLDCW sind iA über Microcode gelöst, und legen die FPU für viele Takte komplett lahm).Noch schlimmer....die FP-Pipe muss zum Ausführen von FSTCW bzw FLDCW (Flags setzen) komplett leer sein.

In diesem Sinne stimme ich dir zu, dass der Befehl einen Sinn hat :D

Demirug

2004-02-09, 19:03:14

Original geschrieben von zeckensack
Ich hab mal kurz gegoogelt (http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&q=Windows+64+bit+x87+registers&btnG=Google+Search) :freak:

AMD sagt ... (PDF) (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_Porting_Win_DD_to_AMD64_Sept24.pdf):
Convert media instructions to SSE/SSE2 Instructions
Microsoft Windows for AMD64 will not context switch x87, 3DNow!, MMX for 64-bit native threads. This code may be converted to SSE/SSE2 through the use of intrinsic functions.
(Seite 7)

Ich glaube ja Grundsätzlich gerne alles was in Whitepapers steht. Allerdings bin ich etwas verwirrt.

Ich habe hier die Thread CONTEXT Struktur für AMD64 vor mir liegen. Da sind definitive die MMX Register enthalten.

Meine WinNT.h ist vom 09.08.2002 wenn jemand eine neuere hat bitte mal nach CONTEXT_AMD64 suchen. Da in der Nähe muss dann die gesamte Struktur sein.

Was mir auch noch zu denken gibt ist das da was von Device Driver steht. Werden die MMX/FP Register vielleicht nur beim Contextwechsel zwischen Kernel/User nicht gesichert? AFAIR durfte man früher aus einem ähnlichen Grund in Kerneltreibern überhaupt keine FP Register benutzen.

EDIT: Das ist die Struktur

typedef struct DECLSPEC_ALIGN(16) _CONTEXT {

//
// Register parameter home addresses.
//

DWORD64 P1Home;
DWORD64 P2Home;
DWORD64 P3Home;
DWORD64 P4Home;
DWORD64 P5Home;
DWORD64 P6Home;

//
// Control flags.
//

DWORD ContextFlags;
DWORD MxCsr;

//
// Segment Registers and processor flags.
//

WORD SegCs;
WORD SegDs;
WORD SegEs;
WORD SegFs;
WORD SegGs;
WORD SegSs;
DWORD EFlags;

//
// Debug registers
//

DWORD64 Dr0;
DWORD64 Dr1;
DWORD64 Dr2;
DWORD64 Dr3;
DWORD64 Dr6;
DWORD64 Dr7;

//
// Integer registers.
//

DWORD64 Rax;
DWORD64 Rcx;
DWORD64 Rdx;
DWORD64 Rbx;
DWORD64 Rsp;
DWORD64 Rbp;
DWORD64 Rsi;
DWORD64 Rdi;
DWORD64 R8;
DWORD64 R9;
DWORD64 R10;
DWORD64 R11;
DWORD64 R12;
DWORD64 R13;
DWORD64 R14;
DWORD64 R15;

//
// Program counter.
//

DWORD64 Rip;

//
// MMX/floating point state.
//

M128 Xmm0;
M128 Xmm1;
M128 Xmm2;
M128 Xmm3;
M128 Xmm4;
M128 Xmm5;
M128 Xmm6;
M128 Xmm7;
M128 Xmm8;
M128 Xmm9;
M128 Xmm10;
M128 Xmm11;
M128 Xmm12;
M128 Xmm13;
M128 Xmm14;
M128 Xmm15;

//
// Legacy floating point state.
//

LEGACY_SAVE_AREA FltSave;
DWORD Fill;

//
// Special debug control registers.
//

DWORD64 DebugControl;
DWORD64 LastBranchToRip;
DWORD64 LastBranchFromRip;
DWORD64 LastExceptionToRip;
DWORD64 LastExceptionFromRip;
DWORD64 Fill1;
} CONTEXT, *PCONTEXT;

zeckensack

2004-02-09, 19:10:21

Demirug,
wie ist LEGACY_SAVE_AREA definiert? Gibt's da einen Unterschied zwischen Win32 und Win64?

Und was zur Hölle ist ein DWORD64? :crazy:
Und warum zum Teufel kann MS nichtmal in Kernel-Strukturen vernünftiges Alignment machen? :crazy:
Und was in Ra's Namen haben xmm0-xmm15 mit MMX zu tun? :crazy:
*schauder*

Demirug

2004-02-09, 19:27:46

typedef struct _LEGACY_SAVE_AREA {
WORD ControlWord;
WORD Reserved0;
WORD StatusWord;
WORD Reserved1;
WORD TagWord;
WORD Reserved2;
DWORD ErrorOffset;
WORD ErrorSelector;
WORD ErrorOpcode;
DWORD DataOffset;
WORD DataSelector;
WORD Reserved3;
BYTE FloatRegisters[8 * 10];
} LEGACY_SAVE_AREA, *PLEGACY_SAVE_AREA;

Für "normales" X86

typedef struct _FLOATING_SAVE_AREA {
DWORD ControlWord;
DWORD StatusWord;
DWORD TagWord;
DWORD ErrorOffset;
DWORD ErrorSelector;
DWORD DataOffset;
DWORD DataSelector;
BYTE RegisterArea[SIZE_OF_80387_REGISTERS];
DWORD Cr0NpxState;
} FLOATING_SAVE_AREA;

typedef struct _CONTEXT {

//
// The flags values within this flag control the contents of
// a CONTEXT record.
//
// If the context record is used as an input parameter, then
// for each portion of the context record controlled by a flag
// whose value is set, it is assumed that that portion of the
// context record contains valid context. If the context record
// is being used to modify a threads context, then only that
// portion of the threads context will be modified.
//
// If the context record is used as an IN OUT parameter to capture
// the context of a thread, then only those portions of the thread's
// context corresponding to set flags will be returned.
//
// The context record is never used as an OUT only parameter.
//

DWORD ContextFlags;

//
// This section is specified/returned if CONTEXT_DEBUG_REGISTERS is
// set in ContextFlags. Note that CONTEXT_DEBUG_REGISTERS is NOT
// included in CONTEXT_FULL.
//

DWORD Dr0;
DWORD Dr1;
DWORD Dr2;
DWORD Dr3;
DWORD Dr6;
DWORD Dr7;

//
// This section is specified/returned if the
// ContextFlags word contians the flag CONTEXT_FLOATING_POINT.
//

FLOATING_SAVE_AREA FloatSave;

//
// This section is specified/returned if the
// ContextFlags word contians the flag CONTEXT_SEGMENTS.
//

DWORD SegGs;
DWORD SegFs;
DWORD SegEs;
DWORD SegDs;

//
// This section is specified/returned if the
// ContextFlags word contians the flag CONTEXT_INTEGER.
//

DWORD Edi;
DWORD Esi;
DWORD Ebx;
DWORD Edx;
DWORD Ecx;
DWORD Eax;

//
// This section is specified/returned if the
// ContextFlags word contians the flag CONTEXT_CONTROL.
//

DWORD Ebp;
DWORD Eip;
DWORD SegCs; // MUST BE SANITIZED
DWORD EFlags; // MUST BE SANITIZED
DWORD Esp;
DWORD SegSs;

//
// This section is specified/returned if the ContextFlags word
// contains the flag CONTEXT_EXTENDED_REGISTERS.
// The format and contexts are processor specific
//

BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];

} CONTEXT;

Sonst noch welche IA64, PPC, R4000 ?

Was ein DWORD64 ist kann man sich ja wohl denken, oder?

Das sind nicht direkt die Kernelstrukturen.

zeckensack

2004-02-09, 20:13:52

Merkwürdig, das. Wenn jetzt nicht zufällig irgendwo ein
#define SIZE_OF_80387_REGISTERS 0
drinsteckt, dann kann das auch eine Ente gewesen sein.
Ich hab das auch nur hier im Forum aufgeschnappt. ZB hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1449780#post1449780) wurde das diskutiert.

Andererseits sind die Hinweise in den AMD-Dokumenten eigentlich recht deutlich. UA auch das (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD64_Porting_FAQ.pdf).

Can x87 instructions still be used by 64-bit applications?
64-bit applications cannot use x87 instructions because 64-bit operating systems are
not required to preserve the x87 stack across interrupts and context switches. AMD
has gone to great lengths to ensure that SSE/SSE2 math library performance and
accuracy exceeds that of the x87 instruction set. We anticipate no need to use x87
instructions in 64-bit applications.

Und n00n?

Demirug

2004-02-09, 20:37:38

Original geschrieben von zeckensack
Merkwürdig, das. Wenn jetzt nicht zufällig irgendwo ein
#define SIZE_OF_80387_REGISTERS 0
drinsteckt, dann kann das auch eine Ente gewesen sein.
Ich hab das auch nur hier im Forum aufgeschnappt. ZB hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1449780#post1449780) wurde das diskutiert.

Andererseits sind die Hinweise in den AMD-Dokumenten eigentlich recht deutlich. UA auch das (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD64_Porting_FAQ.pdf).

Und n00n?

Nein das sind 80 Byte.

Ich weiss auch nicht was nun stimmt. Da es mir derzeit noch an einer CPU zum testen ermangelt kann ich es leicher auch nicht ausprobieren.

Lokadamus

2004-02-09, 20:43:18

mmm...

Einmal für Vollidioten bitte:
Ist seit dem P4 die FPU nicht auf 64 Bit eingeschränkt ? Wenn AMD sich jetzt daran orientiert, bräuchte es theoretisch im 64-Bit Modus die FPU nicht mehr, weil ein einziges Register diese Aufgabe übernehmen könnte, wenn es Floating Points berechnen könnte ... wo hab ich meine Gedankenfehler ??? müssen einige sein ...

zeckensack

2004-02-09, 20:55:55

Original geschrieben von Lokadamus
mmm...

Einmal für Vollidioten bitte:
Ist seit dem P4 die FPU nicht auf 64 Bit eingeschränkt ?Nein. Der P4 ist vollständig abwärtskompatibel zum 486er, dh er kann mit der klassischen "x87-FPU" Fliesskommaberechnungen mit bis zu 80 Bit Präzision ausführen. SSE2 erlaubt ihm zusätzlich die Arbeit mit Vektor-Operanden. Und hier stimmt's dann wieder: SSE2 kann maximal 64 Bit-Zahlen verarbeiten.
Wenn AMD sich jetzt daran orientiert, bräuchte es theoretisch im 64-Bit Modus die FPU nicht mehr, weil ein einziges Register diese Aufgabe übernehmen könnte, wenn es Floating Points berechnen könnte ...Das hat mit dem 64Bit-Modus nichts zu tun. Die FPU-Register waren schon immer 80 Bit breit. Der 64Bit-Modus verbreitert nur die Integer-Register.

Coda

2004-02-09, 21:13:24

@zeckensack:
Nunja, ich frage mich nur für was du die FPU denn noch brauchst.

Die Funktionen die verloren gehen können locker durch code genauso schnell erzeugt werden und werden nicht so oft benötigt, als das sich der Code dadurch übelst aufblähen würde. (Sinus geht z.B. recht gut als Taylor Reihe etc.)

Somit verstehe ich deine Einwände nicht, SSE2 lässt sich dank fehlendem FPU stack sehr viel besser programmieren und ist auch als Compiler Target einfacher zu handhaben...

Gut, das 3DNow! Instructions verloren gehen ist wahr, aber AMD wird irgendwann auch PNI unterstützen.

Ich halte es nach wie vor für eine gute Idee

Ich halte diesen Schritt für sehr unsinnig. Ich kann mir auch nicht vorstellen das diese Konvertiererei nicht ohne Leistungsverlust von statten geht. Ich bin mal gespannt was da auf uns zukommt. In den nächsten Monaten werden wir mehr wissen.
Warum sollte es einen Leistungsverlust geben. Die Funktionseinheiten sind sowieso die gleichen und für den Prozessor ist SSE2 scalar sicher weniger Arbeit als x87. Wobei ich glaube dass das beim A64 sowieso keinen großen Unterschied machen würde.

zeckensack

2004-02-09, 22:32:45

Original geschrieben von Coda
@zeckensack:
Nunja, ich frage mich nur für was du die FPU denn noch brauchst.Und ich frage mich, warum du sie loswerden willst. Diese Debatte haben wir schonmal geführt und ich habe kein einziges Argument für diese Veränderung gehört. "Irgendwie geht's auch ohne" ist kein Argument. Wenn du tatsächlich glaubst dass es eins ist, dann lautet meine Antwort "Irgendwie geht's auch mit".

Was wird dadurch denn besser?
Das (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1488567#post1488567)?

Original geschrieben von zeckensack
Der gesamte FPU-Kontext (respektive MMX, respektive 3DNow) kostet 82 Byte pro Taskswitch.

Muh-sagt-die-Kuh

2004-02-10, 01:34:01

Original geschrieben von zeckensack
Und ich frage mich, warum du sie loswerden willst. Diese Debatte haben wir schonmal geführt und ich habe kein einziges Argument für diese Veränderung gehört. "Irgendwie geht's auch ohne" ist kein Argument. Wenn du tatsächlich glaubst dass es eins ist, dann lautet meine Antwort "Irgendwie geht's auch mit".

Was wird dadurch denn besser?Man hat immer Code ohne größere FXCH Orgien ;)

Ich persönliche sehe auch keinen Grund, den x87 Befehlssatz wegzuwerfen...er schadet doch in keinster Weise, wer ihn benutzen will soll es tun, wer nicht soll es einfach lassen.

GloomY

2004-02-10, 06:41:05

So langsam sollte ich mich auch nochmal tiefer mit Assembler beschäftigen. Kann sicherlich nicht schaden :)
Original geschrieben von zeckensack
Und ich frage mich, warum du sie loswerden willst. Diese Debatte haben wir schonmal geführt und ich habe kein einziges Argument für diese Veränderung gehört. "Irgendwie geht's auch ohne" ist kein Argument. Wenn du tatsächlich glaubst dass es eins ist, dann lautet meine Antwort "Irgendwie geht's auch mit".

Was wird dadurch denn besser?
Das (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1488567#post1488567)? Das ist so eine typische CISC vs. RISC Frage. Der eine macht es lieber in der Hardware, verbrät dadurch eine Menge Transistoren, der andere löst das Problem lieber durch Softwarebibliotheken, was aber sehr wahrscheinlich langsamer ist. Der Code wird größer (=> geringere Hit-Rate des L1 Code Caches), aber der Prozessor wird billiger.

Beide Implementationen haben ihre Vor- und Nachteile, und man kann darüber streiten, was denn nun besser ist. Es aber im Nachhinein abzuschaffen und damit die Kompatiblilität auf's Spiel zu setzen, halte ich natürlich ebenso für Blödsinn. Oder werden bei 32 Bit Programmen in einer 64 Bit Umgebung die FPU Register gesichert und dagegen bei den (gleichzeitig laufenden) 64 Bit Programmen nicht? :???:

Imho hat FXCH auf modernen Prozessoren (wozu man den P4 an dieser Stelle nicht zählen darf *eg* ) Null Takte Latenz. Statt direkt eine FP-Operation zu machen, muss man halt noch jeweils vorne und hinten dran ein FXCH hängen, um den Umweg über das oberste Stack-Element zu machen. Das kostet etwas Platz im Code und beansprucht die Decoder stärker, aber das ist auch schon alles.

Ikon

2004-02-10, 18:08:17

Ich finde es vor allem schockierend, dass MS durch seine Monopolposition solche hirnrissigen Entscheidungen auch noch durchdrücken kann. Schließlich resultieren aus der Nutzung der traditionellen FPU keine Nachteile, und nebenbei wird die maximale Genauigkeit von 80bit auf 64bit gesenkt (welche bei wissenschaftlichen Anwendungen durchaus fehlen könnte).

Ober! Ein Genickschuss für Herrn Gates, bitte.

BlackBirdSR

2004-02-10, 18:57:49

Original geschrieben von Ikon
Ich finde es vor allem schockierend, dass MS durch seine Monopolposition solche hirnrissigen Entscheidungen auch noch durchdrücken kann. Schließlich resultieren aus der Nutzung der traditionellen FPU keine Nachteile, und nebenbei wird die maximale Genauigkeit von 80bit auf 64bit gesenkt (welche bei wissenschaftlichen Anwendungen durchaus fehlen könnte).

Ober! Ein Genickschuss für Herrn Gates, bitte.

ich glaube ehrlich gesagt, dass AMD hier der treibende Faktor war..

man wollte doch bereits mit TFP ein neues FPU Modell einführen...
dies hat man dann zugunsten von SSE2 verworfen, und nun dient SSE2 als FPU Ersatz.
Warum jetzt genau... k.A, AMD wird sich schon was dabei gedacht haben.

Ikon

2004-02-10, 19:07:03

Original geschrieben von BlackBirdSR
Warum jetzt genau... k.A, AMD wird sich schon was dabei gedacht haben.

Die große Frage ist natürlich was sich AMD davon versprechen könnte? Man kann bei einer x86-CPU schließlich nicht einfach die FPU einsparen.

CrazyIvan

2004-02-10, 22:43:07

Ganz blöde Hypothese:

Wieso sollte AMD denn unbedingt x86 konform bleiben?
Mit x86-64 haben die ja schon nen neuen Standard geschaffen. Und wenn ich net ganz falsch liege, dann sollten doch herkömmliche 32-bit Programme dank WOW64 gar nix davon mitkriegen...

Mit 16 bit isses zwar dann bestimmt Essig, but who cares?

Vielleicht schleppen die die FPU noch ein, zwei Generationen mit und hauen sie dann über Board.

/edit: Rächtschraipunk

HOT

2004-02-10, 22:44:59

Original geschrieben von Ikon
Die große Frage ist natürlich was sich AMD davon versprechen könnte? Man kann bei einer x86-CPU schließlich nicht einfach die FPU einsparen.

haben sie ja auch nicht und ich denke nicht dass sie das werden. Nur wird FPU demnächst womöglich nicht mehr so grosszügig dimensioniert ausfallen (und die IST grosszügig dimensioniert :D).

Muh-sagt-die-Kuh

2004-02-10, 23:27:26

Original geschrieben von CrazyIvan
Vielleicht schleppen die die FPU noch ein, zwei Generationen mit und hauen sie dann über Board.
Bring bitte nicht den Befehlssatz und die Ausführungseinheit auseinander....eine FPU (Floating Point Unit) wird auch ohne den x87 Befehlssatz für z.B. SSE2 Berechnungen gebraucht.

BlackBirdSR

2004-02-10, 23:29:40

Original geschrieben von Muh-sagt-die-Kuh
Bring bitte nicht den Befehlssatz und die Ausführungseinheit auseinander....eine FPU (Floating Point Unit) wird auch ohne den x87 Befehlssatz für z.B. SSE2 Berechnungen gebraucht.

hmm Prescott hat Beides angeblich schon getrennt, und wieder extra SIMD Einheiten.
Gut möglich, dass man früher oder später die x87 FPU über Bord schmeissen will

Ikon

2004-02-10, 23:42:16

Original geschrieben von BlackBirdSR
Gut möglich, dass man früher oder später die x87 FPU über Bord schmeissen will

Das würde die Abwärtskompatibilität völlig ruinieren (ich kann mir nicht vorstellen dass man soweit gehen wird).

Aber ihr bringt mich auf eine gute Idee: AMD könnte SIMD mehr oder weniger von der FPU abkoppeln und diese auf ein funktionales Minimum reduzieren. Das wäre eine extremere Variante von Intels P4-Strategie (hohe SIMD-Leistung und grottige x87-Performance). In der FPU ließen sich beim Athlon sicher einige Transistoren sparen (und in diesem Bereich ist man im Gegensatz zu SIMD nicht mehr wirklich gezwungen an Leistung zuzulegen).

zeckensack

2004-02-10, 23:51:41

Original geschrieben von CrazyIvan
Ganz blöde Hypothese:

Wieso sollte AMD denn unbedingt x86 konform bleiben?
Mit x86-64 haben die ja schon nen neuen Standard geschaffen. Und wenn ich net ganz falsch liege, dann sollten doch herkömmliche 32-bit Programme dank WOW64 gar nix davon mitkriegen...Da liegst du falsch ;)
WOW64 tunnelt lediglich ein paar APIs. 32 Bit-Code will ja auch OS-Funktionen nutzen. Der Programmcode selbst wird aber nicht emuliert oä, der muss schon noch direkt von der CPU ausgeführt werden.

Man könnte höchstens für jeden x87-Befehl eine "invalid instruction"-Exception schmeissen und auf die Weise eine echte Software-Emulation erreichen. Die 'Performance' einer solchen Lösung will ich mir garnicht erst vorstellen müssen ...

Coda

2004-02-11, 10:21:21

Original geschrieben von zeckensack
Und ich frage mich, warum du sie loswerden willst. Diese Debatte haben wir schonmal geführt und ich habe kein einziges Argument für diese Veränderung gehört. "Irgendwie geht's auch ohne" ist kein Argument. Wenn du tatsächlich glaubst dass es eins ist, dann lautet meine Antwort "Irgendwie geht's auch mit".
Vielleicht plant AMD ja x86-64 only CPUs für die Zukunft, die x87 dann nicht mehr haben müssen
Vor allem bei den zukünftigen Opterons könnte ich mir das vorstellen

BlackBirdSR

2004-02-11, 10:40:33

Original geschrieben von Coda
Vielleicht plant AMD ja x86-64 only CPUs für die Zukunft, die x87 dann nicht mehr haben müssen
Vor allem bei den zukünftigen Opterons könnte ich mir das vorstellen

bringt es so viel x87 über Board zu werfen?

Die Register brauche ich ja noch für MMX.. also fallen die nicht weg.
Anstelle von x87 FP Einheiten, brauche ich dann SIMD Einheiten. Da spare ich also ebenfalls nichts ein.
Klar, könnte man hier und dort ein paar Zeilen im Microcode weglassen.. aber macht das Alles den Aufwand wert?

haifisch1896

2004-02-11, 11:13:49

Soll MMX nicht auch über Board gehen, oder habe ich da was falsch verstanden?
Ich habe es im Gedächtnis, dass irgendwo sowas im Zusammenhang mit Longhorn kam...?!?

Coda

2004-02-11, 11:17:18

Anstelle von x87 FP Einheiten, brauche ich dann SIMD Einheiten. Da spare ich also ebenfalls nichts ein.
Wir reden hier von den scalar SSE2 Instructions, nicht von den SIMD

Nunja, eine Pipeline Stage der x87 FPU ist erstmal das komische Stack Gewurstel in brauchbare Microinstructions umzuwandeln, also spart man bei SSE zumindest mal einen Takt
Die Funktionseinheiten sind sowieso für beides die Gleichen

Die Register brauche ich ja noch für MMX.. also fallen die nicht weg.
Man kann fast alle MMX Operationen auch auf die SSE2 Register anwenden

Endorphine

2004-02-11, 12:22:24

Original geschrieben von GloomY
[...]
Imho hat FXCH auf modernen Prozessoren (wozu man den P4 an dieser Stelle nicht zählen darf *eg* ) Null Takte Latenz. [...] Siehe Anhang.

Und auch 5. The FXCH instruction has 0 latency in code sequences. However, it
is limited to an issue rate of one instruction per clock cycle.

Crushinator

2004-02-11, 12:42:14

Ich muß an dieser Stelle mal wieder auf das AMD64 Architecture Programmer’s Manual Volume 1 (s. 352) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf) hinweisen:

"6.11.1 Replace x87 Code with 128-Bit Media Code

Code written with 128-bit media floating-point instructions can operate in parallel on four times as many single-precision floating-point operands as can x87 floating-point code. This achieves potentially four times the computational work of x87 instructions that use single-precision operands. Also, the higher density of 128-bit media floating-point operands may make it possible to remove local temporary variables that would otherwise be needed in x87 floating-point code. 128-bit media code is easier to write than x87 floating-point code, because the XMM register file is flat rather than stack-oriented, and, in 64-bit mode there are twice the number of XMM registers as x87 registers."

Damit hat sich für mich die Diskussion darüber, ob man x87 oder MMX noch wirklich - außer zu Zwecken der Abwärtskompatibilität - braucht erledigt.

BlackBirdSR

2004-02-11, 12:45:31

Original geschrieben von crushinator
Ich muß an dieser Stelle mal wieder auf das AMD64 Architecture Programmer’s Manual Volume 1 (s. 352) (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf) hinweisen:

"6.11.1 Replace x87 Code with 128-Bit Media Code

Code written with 128-bit media floating-point instructions can operate in parallel on four times as many single-precision floating-point operands as can x87 floating-point code. This achieves potentially four times the computational work of x87 instructions that use single-precision operands. Also, the higher density of 128-bit media floating-point operands may make it possible to remove local temporary variables that would otherwise be needed in x87 floating-point code. 128-bit media code is easier to write than x87 floating-point code, because the XMM register file is flat rather than stack-oriented, and, in 64-bit mode there are twice the number of XMM registers as x87 registers."

Damit hat sich für mich die Diskussion darüber, ob man x87 oder MMX noch wirklich - außer zu Zwecken der Abwärtskompatibilität - braucht erledigt.

dummerweise reden wir hier von Single Precision SIMD Code. Nicht unbedingt ein geeigneter Ersatz für die x87 FPU.

Wenn du auf skalar SSE2 zurückgreifst, hast du beim K8 ebenfalls wieder 2 OPs/Cycle und nix ist mit 2x Leistung.