Extended (FP80): "Direkt" nutzbar, oder nur intern?

[aths]

Kann man mit einer 80x87-er FPU nun Extended-Werte speichern und laden, oder lediglich Double-Werte mit Extended-Genauigkeit rechnen lassen?

[Muh-sagt-die-Kuh]

Original geschrieben von aths
Kann man mit einer 80x87-er FPU nun Extended-Werte speichern und laden, oder lediglich Double-Werte mit Extended-Genauigkeit rechnen lassen? x87 Instruction Set:

http://home.zcu.cz/~dudacek/SOJ/manualy/80x87set.pdf

80 bit Werte können geladen und gespeichert werden, siehe die Befehle FLD und FSTP.

[aths]

Sehe ich das richtig, dass der P4 keine FP80-Werte mehr unterstützt, bzw. auf 64 Bit abschneidet?

[Gast]

Original geschrieben von aths
Sehe ich das richtig, dass der P4 keine FP80-Werte mehr unterstützt, bzw. auf 64 Bit abschneidet?

Siehst du falsch ;)

[Coda]

SSE2 unterstützt nur 64 bit.

Die Probleme von 80 bit sind

1) Das Alignment ... (10 byte ... das ist grausam)
2) Das man 80 bit Zahlen nur mit fld in die FPU laden kann und nicht direkt mit den Befehlen verarbeiten kann.
3) Das Format von keinem heutigen Compiler mehr verwendet wird (VC++ auf keinen Fall, GCC bin ich mir nicht ganz sicher)

Intern wird allerdings immer mit 80 bit gerechnet. Zumindest wenn keine flags gesetzt sind.

Unter AMD64/Windows 64 wird die legacy FPU nicht mehr verwendbar sein, da die Register beim Task Switch nicht gespeichert werden. Wird alles durch SSE/SSE2 ersetzt (SSE2 hat auch skalare Instructions)

[Demirug]

GCC kann es angeblich noch. Der long double wird dort nicht zu double. Es gibt sogar eine spezialversion des GCC der bei einem sizeof(long double) 16 zurückliefert damit das Alignment nicht so grausam ist.

[Bokill]

@aths

Was brütest du aus?

Die letzten Threads sind doch nicht zufällig oder?

PS: Grosses Lob an das Forum... hier sind deutlich meine Grenzen.
Ich betrachten den Aufbau und die Logik von CPUs nur als Black- Boxes.

Aber lauschen und horchen darf man doch oder?

Spezielle Tips was Literatur angeht, oder muss ich wirklich programmieren lernen, damit ich tieferes Verständnis über CPU- Architektur erlerne?

MFG Bokill

[Coda]

Normalerweiße kannst du als Normalsterblicher nur Assembler lernen um mehr über CPUs zu erfahren

Also ohne Programmieren wirds schwierig

[Crushinator]

Original geschrieben von Coda
3) Das Format von keinem heutigen Compiler mehr verwendet wird (VC++ auf keinen Fall, GCC bin ich mir nicht ganz sicher) Nicht nur GCC sondern auch Borlands Compiler können's noch heute.
Unter AMD64/Windows 64 wird die legacy FPU nicht mehr verwendbar sein, da die Register beim Task Switch nicht gespeichert werden. Wird alles durch SSE/SSE2 ersetzt (SSE2 hat auch skalare Instructions) Jo, ist aber auch nicht weiter schlimm weil:

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)

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

[Endorphine]

Original geschrieben von Bokill
Spezielle Tips was Literatur angeht, oder muss ich wirklich programmieren lernen, damit ich tieferes Verständnis über CPU- Architektur erlerne? Richtiges (!) Verständnis für eine Hardwarearchitektur wird man imho nur bekommen, wenn man sie selbst programmiert. Und das am besten so maschinennah wie möglich. Ich habe durch x86-Assembler ziemlich viel begriffen, warum manche Dinge so sind, wie sie sind (klingt sicher blöd :D).

Man merkt dann, wie man vorher nur an der Oberfläche herumgekratzt und eigentlich nichts verstanden hat. Ich sollte wieder mit Assembler anfangen. ;(

[Demirug]

Wobei man natürlich auch sagen muss das sich x86-Assembler zunehmend von dem was wirklich in der CPU passiert entfernt.

[Ailuros]

Was brütest du aus?

Die letzten Threads sind doch nicht zufällig oder?

Wenn es das ist was ich verdaechtige, wird noch einer meiner Wuensche erfuellt. Komischerweise hab ich es vorgestern wieder bei B3D erwaehnt. Falls ich nicht falsch liegen sollte, waere eine englische Version ein Muss. :)

[aths]

Original geschrieben von Demirug
GCC kann es angeblich noch. Der long double wird dort nicht zu double. Es gibt sogar eine spezialversion des GCC der bei einem sizeof(long double) 16 zurückliefert damit das Alignment nicht so grausam ist. Handelt es sich dabei um dieses komische Format, welches vom 128-Bit-FP die letzten 49 Bits nicht nutzt (was dann quasi "Extended" entspricht?)


Original geschrieben von Coda
Intern wird allerdings immer mit 80 bit gerechnet. Zumindest wenn keine flags gesetzt sind. Wie, rechnet er tatsächlich immer mit 80 Bit, oder nutzt er nicht nur die 80-Bit-Darstellung, rechnet aber lediglich die erforderliche Genauigkeit aus? Bei mir (P4) ist Single noch immer deutlich schneller, als Double. Afaik "entpackt" die FPU Single oder Double ins Extended-Format und "packt" wieder zurück, aber rechnet nur so lange, bis die erforderliche Genauigkeit erreicht ist.


Original geschrieben von Gast
Siehst du falsch ;) Habe es mal getestet. Wenn ich Extended verlange, gibt mir Delphi nur Double-Genauigkeit. Die SizeOf-Funktion allerdings gibt eine 10 zurück. Schon komisch. Woran könnte das liegen?

[Coda]

Jo, ist aber auch nicht weiter schlimm weil
Hab ich gesagt, dass das schlimm ist? Das ist eher besser als der x87 Schrott ...

Wie, rechnet er tatsächlich immer mit 80 Bit, oder nutzt er nicht nur die 80-Bit-Darstellung, rechnet aber lediglich die erforderliche Genauigkeit aus? Bei mir (P4) ist Single noch immer deutlich schneller, als Double. Afaik "entpackt" die FPU Single oder Double ins Extended-Format und "packt" wieder zurück, aber rechnet nur so lange, bis die erforderliche Genauigkeit erreicht ist.
Also bei einem C/C++ Program bei dem nichts an den Flags manipuliert wird, ist das so. Der Performance unterschied kommt von der geringeren Datenmenge zum/vom Speicher

Es gibt ja nur fmul nicht fmul32 oder sowas ... du kanns wie gesagt die Präzission der FPU verstellen, aber das macht der Compiler nicht selber.

[zeckensack]

Original geschrieben von Coda
SSE2 unterstützt nur 64 bit.

Die Probleme von 80 bit sind

1) Das Alignment ... (10 byte ... das ist grausam)
2) Das man 80 bit Zahlen nur mit fld in die FPU laden kann und nicht direkt mit den Befehlen verarbeiten kann.
Intel und AMD empfehlen beide 16 Byte-Alignment für long doubles. Dabei sind logischerweise jeweils 6 Byte purer Ballast.

edit: SSE/SSE2 sind bezüglich Alignment und load-use auch purster shice.

Unter AMD64/Windows 64 wird die legacy FPU nicht mehr verwendbar sein, da die Register beim Task Switch nicht gespeichert werden. Wird alles durch SSE/SSE2 ersetzt (SSE2 hat auch skalare Instructions) Oh weh, warum das denn schon wieder!?
Was ist mit MMX?
(das sind bekanntermassen die selben Register)

[Coda]

Oh weh, warum das denn schon wieder!?
Weil x87 für die CPU und den Compiler ziemlich schlecht is (Stack O_o). x87 ist alt und modrig, höchste Zeit, dass das verschwindet.

Und die 80 bit braucht wirklich kein Mensch, wenn du darauf hinaus willst ...

Btw. der Athlon 64 hat sowieso keine extra Einheiten für SSE2, das geht alles durch die gleiche FPU wie x87

Auch kein MMX mehr, SSE2 hat auch Integer Instructions und AMD64 hat eh doppelt so viele SSE2 Register.

edit: SSE/SSE2 sind bezüglich Alignment und load-use auch purster shice.
Wieso, passt doch wunderbar 128 bit ... Das ist nicht so "ungerade" wie 80 bit, wo viel Platz verschenkt werden muss.

[zeckensack]

Original geschrieben von Coda
Wieso, passt doch wunderbar 128 bit ... Das ist nicht so "ungerade" wie 80 bit, wo viel Platz verschenkt werden muss. Dass jeder Vektor-Operand im Speicher 16-Byte-aligned sein muss, finde ich wahrlich nicht "wunderbar". MMX/3DNow! kamen auch ohne solche Restriktionen aus.

Um 'unpassende' Vektoroperanden zu benutzen, muss man diese erstmal vie MOVUPS in ein Register laden. Sinnlose Verschwendung, sowohl von Code (=potentieller Durchsatz) und natürlich des Registers. Und das nur, weil Intel unfähig war, es gleich vernünftig zu machen. Spekulation: man musste unbedingt ein paar Benchmarks gegen den Athlon gewinnen ...

Und ja, MMX&3DNow! zusammen sich in Punkto Integer-Instruktionen mächtiger als SSE(/2). Ein Jammer ...

nochmal edit:
Wenn man MMX wegschmeisst, verliert man auch Teile von SSE, CVTPS2PI zB hat ein MMX-Register als Ziel (und natürlich ein SSE-Register als Quelle).

[Coda]

Du weißt schon das unaligned data ziemlich schlecht ist beim Speicherzugriff? Das ist eher ne Maßnahme, das die Entwickler/Compiler gezwungen werden es "richtig" zu machen.

Wenn man MMX wegschmeisst, verliert man auch Teile von SSE, CVTPS2PI zB hat ein MMX-Register als Ziel (und natürlich ein SSE-Register als Quelle).
Sicher... das braucht man dann ja aber nicht

[HajottV]

Original geschrieben von Coda
Unter AMD64/Windows 64 wird die legacy FPU nicht mehr verwendbar sein, da die Register beim Task Switch nicht gespeichert werden. Wird alles durch SSE/SSE2 ersetzt (SSE2 hat auch skalare Instructions)

Das stimmt aus zwei Gründen sicher nicht...

0) SSE2 hat keine Instruktionen zum Exponentieren, Logarithmieren oder SIN/COS. Darauf kann man nicht verzichten.

1) Wenn die FPU-Register nicht gespeichert werden, funzt MMX nicht.

Gruß

Jörg

[zeckensack]

Original geschrieben von Coda
Du weißt schon das unaligned data ziemlich schlecht ist beim Speicherzugriff?Ja. Nicht immer hat man die Möglichkeit, dagegen etwas zu unternehmen. Etwa wenn man libs schreibt, und die Daten von ausserhalb kommen. Und bei weitem nicht alle komplexeren Datenströme liegen als "structure of arrays" vor. Aus 5 Millionen Zahlen die Wurzel ziehen kann jeder, die Realität sieht jedoch anders aus.
Das ist eher ne Maßnahme, das die Entwickler/Compiler gezwungen werden es "richtig" zu machen.Wenn der Prozessor damit ein Problem hat (was ich ja durchaus nachvollziehen kann), dann soll er das bitteschön selbst lösen. Ein, zwei Strafzyklen extra nehme ich in kauf wenn die Adresse nicht 'aligned' ist. Dass ich gleich ganz anderen Code benutzen muss, nur wenn die Adresse nicht aligned sein könnte, das schmeckt mir absolut nicht.
Sicher... das braucht man dann ja aber nicht Warum nicht? Wie willst du diese Instruktion ersetzen, wenn MMX und x87 wegfallen?

[aths]

*Vorsich den Finger heb und umguck, ob noch jemand hören will, was ich frage*

Bitte noch mal konkret :) Sind folgende Aussagen richtig, wenn nein, was ist falsch?

1) Auch P4 hat eine FPU, die FP80-Genauigkeit "nach außen" weitergeben kann.

2) Wenn man davon nichts merkt (siehe Problem in Delphi: Extended vereinbart, Double-Genauigkeit bekommen) ist das die Schuld des Compilers.

3) Sofern man keine weiteren Anstalten macht, ist es der FPU egal, ob man Single, Double oder Extended nimmt, die Rechnungen werden intern immer mit Extended-Genauigkeit ausgeführt, danach wird die Zahl ggf. auf Single bzw. Double eingedampft.

4) Wird mit Extended gerechnet, hat man keine Hidden Bits mehr (die Rechnung wird mit ungepackter 64-Bit-Mantisse ausgeführt.)

5) Aus Alignement-Gründen reserviert man ggf. 128 Bit für ein Extended.

6) Es gibt Rechner (z. B. Sparcs) die aber tatsächlich Quad bzw. Double Extended (volle 128-Bit-Genauigkeit) rechnen können.

[micki]

1) ja, weil voll kompatibel zu vorherigen cpus, und die konnten das
2) es ist nicht unbedingt die schuld des compilers. wenn das OS nur 64bit sichert, dann kann man nicht mit mehr rechnen, weil beim taskswitch die bits verfälscht werden würden, wobei ich jetzt nicht weiß wie das genau bei windows abläuft, wenn du einen task auf timecritical setzt während du deine berechnungen durchführst und kein taskswitch auftaucht, dann solltest du (mit entsprechendem fpu setup) mit voller genauigkeit durchgelaufen sein.. denk ich mir. (natürlich must du den compiler dazu dann zwingen oder gleich assembler coden)

3) je nachdem was dein programm einstellt passiert das, bei windows ist default 64bit soweit ich weiß.
normalerweise ist es für die performance auch nicht soo wichtig welche genauigkeit genutzt wird, denn nur fdiv und fsqrt (und vielleicht sin?) werden dadurch ein wenig schneller.

4)ja

5)ja, kommt auch ein wenig auf die datenmenge an, wenn du ein sehr grosses array hast, dann könnte es ohne allignment schneller sein.

6)sicherlich gibt es solche rechner, es gibt auch rechner/cpus die mit 256bit rechnen


ich werd hier noch sicher viel korrigiert werden, aber so weiß ich es :D

MfG
micki

[HajottV]

1) Ja

2) Kann zu Delphi nichts sagen

3) Formulieren wir es so: Wenn der Compiler die FPU (und nicht eine SSE/SSE2 Einheit) benutzt, werden Rechnungen intern immer mit Extended-Genauigkeit ausgeführt, beim Wegschreiben wird die Zahl ggf. auf Single bzw. Double eingedampft.

4) Ja

5) Ja

6) Vermutlich

Gruß

Jörg

[HajottV]

Original geschrieben von micki
wenn das OS nur 64bit sichert, dann kann man nicht mit mehr rechnen, weil beim taskswitch die bits verfälscht werden würden, wobei ich jetzt nicht weiß wie das genau bei windows abläuft, wenn du einen task auf timecritical setzt während du deine berechnungen durchführst und kein taskswitch auftaucht, dann solltest du (mit entsprechendem fpu setup) mit voller genauigkeit durchgelaufen sein.. denk ich mir. (natürlich must du den compiler dazu dann zwingen oder gleich assembler coden)


Nenene, der Zustand der FPU wird beim x86 mit FSAVE gesichert, das speichert die kompletten 80 Bit jedes ST(x)-Registers ab.

Ein Taskswitch, der die Register verfälscht??? Sozusagen Lossy-Switch? Glaubst Du das ernsthaft?

"Time critical" (was immer das bei Dir genau zu bedeuten haben mag) weist den Scheduler an, dem Task mehr/längere Timeslices (Realtime-OS klammere ich hier mal aus) zu geben. Eine Unterbrechung kann trotzdem an jeder beliebigen Stelle (wieder ausgeklammert LOCK) erfolgen (auch, wenn man in ASM programmiert). Wie sollte denn sonst präemptives Multi-Tasking funktionieren?

Gruß

Jörg

[zeckensack]

Original geschrieben von HajottV
Nenene, der Zustand der FPU wird beim x86 mit FSAVE gesichert, das speichert die kompletten 80 Bit jedes ST(x)-Registers ab.Ack. Sowohl die NASM-Doku, als auch Intel selber geben an, dass die vollen 80 bit jedes Registers gespeichert werden.

[zeckensack]

Original geschrieben von aths
3) Sofern man keine weiteren Anstalten macht, ist es der FPU egal, ob man Single, Double oder Extended nimmt, die Rechnungen werden intern immer mit Extended-Genauigkeit ausgeführt, danach wird die Zahl ggf. auf Single bzw. Double eingedampft.Jein. Die FPU hat nur 80 Bit-Register ... und damit rechnet sie.
Das "eindampfen" auf double oder float erfolgt erst beim Schreiben der Ergebnisse in den Speicher. Es hängt vom Code und vom Compiler ab, wie oft und wieviel 'zwischendurch' in den Speicher geschrieben und wieder zurückgeladen wird. Grundsätzlich ist es aber möglich, mit bis zu acht Zwischenergebnissen (die durchaus als "float" deklariert sein können!) völlig innerhalb der FPU, also 80bittig zu rechnen.

Es gibt dafür zB in MSVC einen Compiler-Switch, der "improve float consistency" heisst. Hat Delphi evtl auch so etwas? ?(

[Demirug]

Wo wir gerade bei Compilerswitchs sind. Hat schon jemand den SSE2 Codeoptimierer von MSVC 7 ausprobiert?

[micki]

Original geschrieben von HajottV
Nenene, der Zustand der FPU wird beim x86 mit FSAVE gesichert, das speichert die kompletten 80 Bit jedes ST(x)-Registers ab.

Ein Taskswitch, der die Register verfälscht??? Sozusagen Lossy-Switch? Glaubst Du das ernsthaft?
ja, ich glaube dass das OS nicht zwingend die von der Hardware möglichen dinge unterstützen muss und eventuell selbst weniger genauigkeit unterstüzen kann. es wäre somit keine verfälschung der daten sondern arbeiten innerhalb der selbst definierten parameter.
immerhin rundet ein c-compiler auch anders als die fpu per default tun würde, bzw verfälscht die daten um es mit deinen worten auszudrücken.

Original geschrieben von HajottV
"Time critical" (was immer das bei Dir genau zu bedeuten haben mag) weist den Scheduler an, dem Task mehr/längere Timeslices (Realtime-OS klammere ich hier mal aus) zu geben. Eine Unterbrechung kann trotzdem an jeder beliebigen Stelle (wieder ausgeklammert LOCK) erfolgen (auch, wenn man in ASM programmiert). Wie sollte denn sonst präemptives Multi-Tasking funktionieren?

man kann unter Windows prioritäten setzen, eine davon ist time critical, damit kann man das system fast vollkommen abblocken bis der eigene thread seine arbeit einstellt oder die priorität senkt.
wenn du ein hersteller eines ausreichend grossens software projects bist und bei m$ ganz lieb anfragst, bekommst du auch spezielle funktionen zu verfügung mit denen du 100% rechenlast für deinen process reservieren kannst (soll von Mayas copyprotections genutzt werden, angäblich). wie gesagt, sowas kann ein OS für sich definieren, egal was mein oder dein glaube über multitasking vorschreibt.


Original geschrieben von Zeckensack
Jein. Die FPU hat nur 80 Bit-Register ... und damit rechnet sie.
Das "eindampfen" auf double oder float erfolgt erst beim Schreiben der Ergebnisse in den Speicher.


wenn man die fpu flags umstellt, rechnet die fpu nicht mehr mit 80 bit, sie speicher die werte zwar in den 80bit registern, aber sie rechnet dann nicht mehr mit der vollen genauigkeit. einige 3d engines setzen die fpu flags so, dass sie nur noch float rechnet, (trotz 80bit register) hat man dann nur noch 32bit genauigkeit.

"
The PC field (bits 9 and 8) or Precision Control determines to what precision the FPU rounds results after each arithmetic instruction in one of three ways:

00 = 24 bits (REAL4)
01 = Not used
10 = 53 bits (REAL8)
11 = 64 bits (REAL10) (this is the initialized state)"
source:
http://www.masmforum.com/website/tutorials/fptute/fpuchap1.htm


MfG
micki

[Muh-sagt-die-Kuh]

Original geschrieben von HajottV
Das stimmt aus zwei Gründen sicher nicht...

0) SSE2 hat keine Instruktionen zum Exponentieren, Logarithmieren oder SIN/COS. Darauf kann man nicht verzichten.

Gruß

Jörg Darauf kann man verzichten, lässt sich alles in Software mit den bekannten Instruktionen nachbilden.....ob man nun die CPU direkt mit Code zur Berechnung von z.B. SIN füttert oder das (bei heutigen CPUs) der Microcode-Sequencer übernimmt ist der CPU selbst ziemlich egal....stresst nur das gesamte Speichersubsystem etwas mehr.

P.S.: Die IA-64 ISA kennt nichtmal einen Divisionsbefehl ;)

[Coda]

Windows sichert garantiert alle 80 bit, weil ja intern mit 80 bit gerechnet wird, wenn dann da auf einmal die Hälfte fehlt wär das ziemlich dumm...

IA-64 kann z.B. 128 bit FP

fsin usw. sind eh nur ballast, es gibt angeblich keine einzige andere Architektur die noch nen Sinus opcode kennt

Hat schon jemand den SSE2 Codeoptimierer von MSVC 7 ausprobiert?
Den hat erst MSVC 7.1
Aber das meiste was er macht ist normalen FPU code durch SSE2 skalar instructions auszutauschen ;)