Untersuchung: Seltsame Diskrepanz bei Inline-ASM

[Helmut Schellong]

Folgende Testdatei:
--------------------------------------------
static long double sd(void)
{
long double y;
__asm__ ("\n\t"
"fldpi \n\t"
"fld1 \n\t"
"fdivp \n\t"
: "=t"(y)
:
:
); // st(1)=pi, st(0)=1
return y;
}



int main(void)
{
printf("\t%.18Lg\n", sd());
return 0;
}
--------------------------------------------

Ergibt das Resultat: 0.318309886183790672 = 1/pi
Diese falsche Operation erhalte ich mit: clang6, gcc9, bcc32x.exe (Embarcadero).
Es müßte korrekterweise pi = pi/1 gerechnet werden.

Diese Fehlerhaftigkeit betrifft: FDIV, FDIVR, FSUB, FSUBR.

Intel:
FDIV ST(0), ST(i) D8 F0+i Divide ST(0) by ST(i) and store result in ST(0).
FDIV ST(i), ST(0) DC F8+i Divide ST(i) by ST(0) and store result in ST(i).
FDIVP ST(i), ST(0) DE F8+i Divide ST(i) by ST(0), store result in ST(i), and pop the register stack.
FDIVP DE F9 Divide ST(1) by ST(0), store result in ST(1), and pop the register stack.

AMD:
FDIV ST(0), ST(i) D8 F0+i Replace ST(0) with ST(0)/ST(i).
FDIV ST(i), ST(0) DC F8+i Replace ST(i) with ST(i)/ST(0).
FDIVP ST(i), ST(0) DE F8+i Replace ST(i) with ST(i)/ST(0), and pop the x87 register stack.
FDIVP DE F9 Replace ST(1) with ST(1)/ST(0), and pop the x87 register stack.

Die Situation ist eindeutig.
Bei einer ASM-Funktions-Lib von 1991 hatte ich damals die _richtige_ Operation erhalten.
Wenn ich die als Grundlage verwende, muß ich alle FDIV, FSUB, FDIVR, FSUBR
in die jeweilige Reverse-Instruktion verwandeln, um heute korrekte Ergebnisse zu erhalten!

Das betrifft nachfolgend fsubr und fdivr, wo das 'r' weg muß:
-----------------------------------------------------------
; sc/24.1.91
TITLE acos87
.386
.387
.MODEL small
PUBLIC _acos87
.DATA
COMM _deg_87:DWORD
.DATA?
.CONST
$radtodeg DT 57.295779513082320876798
ALIGN 4
.CODE
_acos87 PROC
fld QWORD PTR [esp+4]
fld st
fmul st, st
fld1
fsubr
fsqrt
fdivr
fld1
fpatan
mov eax, _deg_87
cmp eax, 0
jg SHORT $deg
ret
ALIGN 4
$deg:
fld $radtodeg
fmul
ret
ALIGN 4
_acos87 ENDP
END
-----------------------------------------------------------

Ich will ja nicht hoffen, daß das an der AT&T-Assembler-Darstellung liegt,
wo das Zielobjekt stets rechts statt links dargestellt werden muß.

Das betrifft jedoch nur die Reihenfolge der Operanden in der _Darstellung_.
Statt 'inst st(1), st(0)' muß halt 'inst st(0), st(1)' geschrieben werden.
st(0) und st(1) bleiben ja st(0) und st(1)!


--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/dragon.c.html

[Bonita Montero]

Äh, wer benutzt heute denn noch die x87-FPU ? Ich meine das passiert
doch eigentlich nur noch manchmal, wenn man Code 32-bittig kompiliert.
Ansonsten ist heute SSE 4.1 Standard.
Die ganze Stack-Logik der x87-FPU ist echt eine technische Missgeburt.

[Helmut Schellong]

On 06/10/2022 07:25, Bonita Montero wrote:
> Äh, wer benutzt heute denn noch die x87-FPU ? Ich meine das passiert
> doch eigentlich nur noch manchmal, wenn man Code 32-bittig kompiliert.
> Ansonsten ist heute SSE 4.1 Standard.

Das ist oft unsinnig.
Welche mathematischen Operationen kann SSE denn durchführen?
Nämlich nur die vier Grundrechenarten und übliche bit-weise Operationen.
Und 'long double' geht nicht.

Mit der FPU x87 kann man z.B.:

sin() cos() tan() cot() sec() csc()
asin() acos() atan() acot() asec() acsc()
sinh() cosh() tanh() coth() sech() csch()
asinh() acosh() atanh() acoth() asech() acsch()
sqrt() pow() log() lg() ln() ld() ilg() iln() ild()

verwirklichen, und _viele_ weitere.
Bis zu 100-fach schneller als Emulationen.

> Die ganze Stack-Logik der x87-FPU ist echt eine technische Missgeburt.

Nein, wenn man damit konkret gearbeitet hat, hat man den Stack schätzen gelernt.
Vor langer Zeit waren Taschenrechner von HP äußerst beliebt, wegen ihrer
'Umgekehrte polnische Notation'.
Für Profis ist UPN vorteilhaft.

Aus datei.o:
0b+096 c4 10 5d c3 55 48 89 e5 >> d9 eb, d9 e8, de f1 << 5d c3
. ^^^^^ ^^^^^ ^^^^^
Vorstehend sind die Opcodes für Pi, 1, und Division kenntlich gemacht.
Die Division hat den falschen Opcode 'de f1' für 'fdivrp' statt 'de f9' für 'fdivp'.
Es wird tatsächlich von allen erreichbaren Assemblern falsch übersetzt!

[Bonita Montero]

Am 10.06.2022 um 10:39 schrieb Helmut Schellong:

> Mit der FPU x87 kann man z.B.:
>
>    sin() cos() tan() cot() sec() csc()
>    asin() acos() atan() acot() asec() acsc()
>    sinh() cosh() tanh() coth() sech() csch()
>    asinh() acosh() atanh() acoth() asech() acsch()
>    sqrt() pow() log() lg() ln() ld() ilg() iln() ild()

Einiges ist bei SSE 4.1 nicht mehr dabei weil es in Software einfach
effizienter zu implementieren ist. Ich habe z.B. mal eine Sinus- bzw.
Cosinus-Berechnung mit den verbreiteten CORDIC-Algorithmus (absolut
geniale Erfindung) selbst implementiert, und das war im Endeffekt
viermal schneller als FSINCOS. Ich mein diese ganzen komplexen Opera-
tionen wie FSINCOS, FTAN etc. sind ja eh alle weitestgehend in Micro-
code realisiert, dass die eh nicht besonders schnell sind.
Es gibt auch praktisch außer x86/7 keine FPU einer anderen CPU, die
sowas in "Hardware" (letztlich ja Microcode) macht. Ganz einfach weil
die Idee einfach abwegig ist. Einzig FSQRT ist nahezu durchgänig in
Hardware realisiert weil das eben in Hardware gravierend effizienter
geht und das eine häufig gebrauchte Operation ist; und das gilt eben
entsprechend auch für die FPUs anderer CPUs.

> Nein, wenn man damit konkret gearbeitet hat, hat man den Stack schätzen gelernt.

Ach, und aus welchem Grund hat man das bei SSE, AVX & Co nicht mehr
fortgesetzt ? Ganz einfach: weil das dauernde Swappen des obersten
Stack-Elements mit anderen Elementen auf dem Stack so nicht mehr
nötig ist. Das ist für den Entwickler der noch händischen Assembler
-Code schreibt komfortabler zu nutzen, und bei einer OoO-CPU ist
das Register-Renaming viel einfacher zu implementieren, während
die Stack-Logik den Grad an instruction-level parallelism doch
deutlich begrenzt.
Ich mein früher gab es ja HPC-Systeme die noch mit 32-bittigen x86
-CPUs arbeiteten und wo die x87-FPU mangels Alternative genutzt wurde.
Ich mein "HPC" mit so einem Murks ? Da kam ich schon damals ins Stutzen.
Kompilierst Du 64-bittigen Code, so wird die x87-FPU nicht mehr genutzt.
Meines Wissens sogar nicht mehr bei 32-bittigem Code, außer Du sagst
dem Compiler händisch, dass der doch bitte die x87-FPU nutzen soll.
Die x87-FPU hatte lediglich nur den Vorteil, dass die für die häufigst
genutzten Operationen ohne Performance-Verlust mit 80 Bit Genauigkeit
rechnen konnte. Ausnahmen waren Loads und Stores, die wg. der 10-Byte
-Operationen recht langsam waren. Die meisten C/C++-Runtimes haben
das aber bei der Initialisierung auf 64 Bit abgedreht damit die Ergeb-
nisse eben kompatibler zu anderen CPUs sind.

Die x87-FPU ist eigentlich seit SSE2, also seitdem SSE doppelte Präzi-
sion kann, so gut wie kaum genutzt.

[Helmut Schellong]

On 06/10/2022 10:59, Bonita Montero wrote:
> Am 10.06.2022 um 10:39 schrieb Helmut Schellong:
>
>> Mit der FPU x87 kann man z.B.:
>>
>>     sin() cos() tan() cot() sec() csc()
>>     asin() acos() atan() acot() asec() acsc()
>>     sinh() cosh() tanh() coth() sech() csch()
>>     asinh() acosh() atanh() acoth() asech() acsch()
>>     sqrt() pow() log() lg() ln() ld() ilg() iln() ild()
>
> Einiges ist bei SSE 4.1 nicht mehr dabei weil es in Software einfach
> effizienter zu implementieren ist. Ich habe z.B. mal eine Sinus- bzw.
> Cosinus-Berechnung mit den verbreiteten CORDIC-Algorithmus (absolut
> geniale Erfindung) selbst implementiert, und das war im Endeffekt
> viermal schneller als FSINCOS. Ich mein diese ganzen komplexen Opera-
> tionen wie FSINCOS, FTAN etc. sind ja eh alle weitestgehend in Micro-
> code realisiert, dass die eh nicht besonders schnell sind.
> Es gibt auch praktisch außer x86/7 keine FPU einer anderen CPU, die
> sowas in "Hardware" (letztlich ja Microcode) macht. Ganz einfach weil
> die Idee einfach abwegig ist. Einzig FSQRT ist nahezu durchgänig in
> Hardware realisiert weil das eben in Hardware gravierend effizienter
> geht und das eine häufig gebrauchte Operation ist; und das gilt eben
> entsprechend auch für die FPUs anderer CPUs.

Langsam waren die i387 und i487.
Das las ich von 730 Takten für eine komplexe Operation.
Trotzdem war das bis zu 100-fach schneller als Emulatoren.

Jedoch mit dem Pentium 1994 hat sich Sache extrem beschleunigt!
Ich hatte einen mit 60 MHz.
Multiplikation nur 3 Takte.
Alle Operationen, die keine Berechnungen sind, überwiegend 1 Takt.
FILD Integer laden und in 80bit FP umwandeln: 6 Takte.
Inzwischen (1994->) dürfte das noch wesentlich beschleunigt sein.
Mikrocode ist wohl kaum ganz zu vermeiden.
Die Grundlage sind Reihen, die gewiß nicht nach drei Gliedern konvergieren.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264590

Diese Assembler-Fehler haben riesige Konsequenzen...

>> Nein, wenn man damit konkret gearbeitet hat, hat man den Stack schätzen gelernt.
>
> Ach, und aus welchem Grund hat man das bei SSE, AVX & Co nicht mehr
> fortgesetzt ? Ganz einfach: weil das dauernde Swappen des obersten
> Stack-Elements mit anderen Elementen auf dem Stack so nicht mehr
> nötig ist.

Die Konzepte sind bei SSE komplett anders.
Das ist wie bei eax, ebx, ecx, edx, ...
Da würde auch niemand diese Register in einen Stack einbauen.
Statt st(#) dann i(#).
Beim x87 geht es fast nur um Formelberechnung.
Da ist ein Stack-Konzept mit UPN eben vorteilhaft.

> Die x87-FPU ist eigentlich seit SSE2, also seitdem SSE doppelte Präzi-
> sion kann, so gut wie kaum genutzt.

Ich habe oben über 30 Funktionen gezeigt.
Die brauche ich alle unbedingt, und noch viele dazu.
SSE kann ich dafür nicht nutzen.
Funktionen wie mul87(a, b) habe ich auch noch nicht geschrieben.
Das kann von mir aus SSE machen.

[Bonita Montero]

Am 10.06.2022 um 17:06 schrieb Helmut Schellong:

> Langsam waren die i387 und i487.
> Das las ich von 730 Takten für eine komplexe Operation.
> Trotzdem war das bis zu 100-fach schneller als Emulatoren.

Naja, is halt heute fast durchgehend anders.

> Jedoch mit dem Pentium 1994 hat sich Sache extrem beschleunigt!
> Ich hatte einen mit 60 MHz.
> Multiplikation nur 3 Takte.

Wag ich zu bezweifeln, denn das ist heute bei Integer-Multiplikationen
auf aktuellen x86-CPUs so, eine SSE/AVX FP-Multiplikation dauert auf
einer aktuellen Zen3-CPU lt. agner.org auch drei Takte Latenz. Dem
werden sicher nicht irgendwelche altertümlichen CPUs gleichkommen.

> Alle Operationen, die keine Berechnungen sind, überwiegend 1 Takt.
> FILD  Integer laden und in 80bit FP umwandeln: 6 Takte.

Klingt eher realistisch. Und damals konntest Du auch keine Integer
-Register in ein FP-Register transferieren, sondern Du musstest den
Umweg über das RAM nehmen. Heute mit SSE geht das Direkt und eine
32 / 64 Bit Integer zu FP Konvertierung dauert dann auf einer Zen3
-CPU drei Takte.
Moderne FPUs haben aber keine Operationen, Vorzeichen-lose Integer
-Werte in FP-Werte zu wandeln. Wenn ich also im 64-Bit-Modus ein
size_t in einen FP-Wert konvertieren will, dann nehme ich immer
den Umweg über ptrdiff_t, denn das ist nur eine Instruktion.

> Beim x87 geht es fast nur um Formelberechnung.

Ne, das Konzept ist generell bescheuert.

> Da ist ein Stack-Konzept mit UPN eben vorteilhaft.

Für den Compiler gar nicht, für den Assembler-Programmierer nur
so lang bis ein Swap im Stack nötig ist.

> Die brauche ich alle unbedingt, und noch viele dazu.

Selbst mit Library-Call ist das gravierend schneller.
Außerdem bringt's heute Assembler-Programmierung wirklich nur ganz,
ganz selten. Das meiste was ansich nur in Assembler geht und für
was C keine Sprachmittel kennt lässt sich gut mit mit Intrinsics
erschlagen, und da muss man dann einiges an Hirnschlmalz aufwenden,
um einen heutigen Compiler mit gleichwertigem Assembler-Code zu
schlagen.

[Helmut Schellong]

On 06/10/2022 17:33, Bonita Montero wrote:
> Am 10.06.2022 um 17:06 schrieb Helmut Schellong:
>
>> Langsam waren die i387 und i487.
>> Das las ich von 730 Takten für eine komplexe Operation.
>> Trotzdem war das bis zu 100-fach schneller als Emulatoren.
>
> Naja, is halt heute fast durchgehend anders.
>
>> Jedoch mit dem Pentium 1994 hat sich Sache extrem beschleunigt!
>> Ich hatte einen mit 60 MHz.
>> Multiplikation nur 3 Takte.
>
> Wag ich zu bezweifeln, denn das ist heute bei Integer-Multiplikationen
> auf aktuellen x86-CPUs so, eine SSE/AVX FP-Multiplikation dauert auf
> einer aktuellen Zen3-CPU lt. agner.org auch drei Takte Latenz. Dem
> werden sicher nicht irgendwelche altertümlichen CPUs gleichkommen.

https://books.google.de/books?id=HlqCBwAAQBAJ&pg=PA415&lpg=PA415&dq=pentium+gleitkomma-multiplikation+takte&source=bl&ots=yFadIxAi67&sig=ACfU3U1cT5md7vJ01lyTTy14iJIlTl9pcg&hl=de&sa=X&ved=2ahUKEwjQzLuZv6P4AhUA7rsIHYEDB-cQ6AF6BAgFEAE#v=onepage&q=pentium

http://www.schellong.de/pent.htm

> [...]

[Bonita Montero]

Am 10.06.2022 um 20:24 schrieb Helmut Schellong:
> On 06/10/2022 17:33, Bonita Montero wrote:
>> Am 10.06.2022 um 17:06 schrieb Helmut Schellong:
>>
>>> Langsam waren die i387 und i487.
>>> Das las ich von 730 Takten für eine komplexe Operation.
>>> Trotzdem war das bis zu 100-fach schneller als Emulatoren.
>>
>> Naja, is halt heute fast durchgehend anders.
>>
>>> Jedoch mit dem Pentium 1994 hat sich Sache extrem beschleunigt!
>>> Ich hatte einen mit 60 MHz.
>>> Multiplikation nur 3 Takte.
>>
>> Wag ich zu bezweifeln, denn das ist heute bei Integer-Multiplikationen
>> auf aktuellen x86-CPUs so, eine SSE/AVX FP-Multiplikation dauert auf
>> einer aktuellen Zen3-CPU lt. agner.org auch drei Takte Latenz. Dem
>> werden sicher nicht irgendwelche altertümlichen CPUs gleichkommen.
>
> https://books.google.de/books?id=HlqCBwAAQBAJ&pg=PA415&lpg=PA415&dq=pentium+gleitkomma-multiplikation+takte&source=bl&ots=yFadIxAi67&sig=ACfU3U1cT5md7vJ01lyTTy14iJIlTl9pcg&hl=de&sa=X&ved=2ahUKEwjQzLuZv6P4AhUA7rsIHYEDB-cQ6AF6BAgFEAE#v=onepage&q=pentium
>
>
> http://www.schellong.de/pent.htm
>
>> [...]
>
>
>

Ich glaub's immer noch nicht. Schau dir die Tabellen von agner.org
an, da haben wirklich nur die aktuellsten CPUs solche Timings und
die davor schon eben nicht mehr.

[Helmut Schellong]

Dann mußt Du eben mit geeigneter Meßmethode selbst messen, so wie ich das tat.

[Bonita Montero]

Äh, ich habe keine definitven Quellen dazu gefunden, aber eben
Angaben in Foren die recht glaubwürdig klangen und ungefähr dem
entsprachen was ich aus den 90ern in Erinnerung hatte:

http://computer-programming-forum.com/46-asm/7beb58d0ae8ddfc7.htm

Deine Angabe ist unglaubwürdig, denn in dem Rahmen liegen gerade
mal die neuesten x86-CPUs wie Zen3, die Generation davor ist schon
wieder etwas langsamer und ein 486 wird sicher den obigen Angaben
entsprechen, die aus heutiger Sicht jenseits von Gut und Böse sind.

[Helmut Schellong]

Es ist Quatsch, was in Deinen Quellen steht.
Zuallererst, weil ich selbst 3 Takte gemessen habe, beim Pentium-60.
Weiterhin, weil damals u.a. in der c't x-fach auf diese 3 Takte hingewiesen wurde.
Also messe selbst.

--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz

[Bonita Montero]

Ich glaub dir kein Wort, Null, gar nicht.
Wenn das nichtmal mein Zen2 3990X nicht kann,
dann kann das ein uralter 486 sicher erst recht nicht.

[Helmut Schellong]

Spinner, ich schrieb vom Pentium-60, der das kann.
Langeweile?

[Bonita Montero]

Äh, den überwiegenden Teil des Threads schriebst Du vom 486.

[Helmut Schellong]

Ich schrieb überhaupt gar nicht vom 486, in den Postings.
http://www.schellong.de/pent.htm
In vorstehender Datei nur für Vergleichszwecke.

[Bonita Montero]

Naja, Du Nase hast da wohl was grundlegend verkehrt gemacht.
Ich mein ein fünf Jahre alter Zen1 braucht für eined double
* double Multiplikaiton vier Takte; da werden irgendwelche
Antiquitäten wohl nicht mehr Durchsatz pro Takt gemacht
haben.
Sowas unqualifiziertes aber auch, neee.

[Helmut Schellong]

https://www2.math.uni-wuppertal.de/~fpf/Uebungen/GdR-SS02/opcode_f.html

operand 8087 287 387 486 Pentium
fmul reg s 90-105 90-105 29-52 16 3/1 FX
fmul reg 130-145 130-145 46-57 16 3/1 FX
fmul mem32 (110-125)+EA 110-125 27-35 11 3/1 FX
fmul mem64 (154-168)+EA 154-168 32-57 14 3/1 FX
fmulp reg s 94-108 94-108 29-52 16 3/1 FX
fmulp reg 134-148 134-148 29-57 16 3/1 FX

operand 8087 287 387 486 Pentium
fadd 70-100 70-100 23-34 8-20 3/1 FX
fadd mem32 90-120+EA 90-120 24-32 8-20 3/1 FX
fadd mem64 95-125+EA 95-125 29-37 8-20 3/1 FX
faddp 75-105 75-105 23-31 8-20 3/1 FX

operand 8087 287 387 486 Pentium
fsub reg 70-100 70-100 26-37 8-20 3/1 FX
fsub mem32 (90-120)+EA 90-120 24-32 8-20 3/1 FX
fsub mem64 (95-125)+EA 95-125 28-36 8-20 3/1 FX
fsubp reg 75-105 75-105 26-34 8-20 3/1 FX

Das gilt ab dem Pentium-60 von 1994.
Intel hat da eine Art RISC-Pipeline eingebaut, für diese Operationen.
Auch fcom profitiert davon.

Eines sollte man sich merken:
Wenn ich irgendetwas fachliches sage, so stimmt das in nahezu allen Fällen.

--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz

[Bonita Montero]

Am 18.06.2022 um 21:29 schrieb Helmut Schellong:

> https://www2.math.uni-wuppertal.de/~fpf/Uebungen/GdR-SS02/opcode_f.html
>
>     operand       8087         287        387      486     Pentium
>     fmul reg s    90-105       90-105    29-52     16      3/1     FX
>     fmul reg     130-145      130-145    46-57     16      3/1     FX
>     fmul mem32  (110-125)+EA  110-125    27-35     11      3/1     FX
>     fmul mem64  (154-168)+EA  154-168    32-57     14      3/1     FX
>     fmulp reg s   94-108       94-108    29-52     16      3/1     FX
>     fmulp reg    134-148      134-148    29-57     16      3/1     FX
>
>     operand       8087         287        387      486     Pentium
>     fadd         70-100       70-100     23-34     8-20    3/1     FX
>     fadd  mem32  90-120+EA    90-120     24-32     8-20    3/1     FX
>     fadd  mem64  95-125+EA    95-125     29-37     8-20    3/1     FX
>     faddp        75-105       75-105     23-31     8-20    3/1     FX
>
>     operand       8087         287        387      486     Pentium
>     fsub  reg     70-100      70-100     26-37     8-20    3/1     FX
>     fsub  mem32  (90-120)+EA  90-120     24-32     8-20    3/1     FX
>     fsub  mem64  (95-125)+EA  95-125     28-36     8-20    3/1     FX
>     fsubp reg     75-105      75-105     26-34     8-20    3/1     FX
>
> Das gilt ab dem Pentium-60 von 1994.
> Intel hat da eine Art RISC-Pipeline eingebaut, für diese Operationen.
> Auch fcom profitiert davon.

Ob RISC oder nicht, das hat damit nix zu tun.

[Helmut Schellong]

Womit hat es nichts zu tun?
Ab dem Pentium-60 waren die obigen Instruktionen definitiv 3 Takte schnell.
Das ist es, worum es seit einer gehörigen Anzahl von Postings geht.

https://en.wikipedia.org/wiki/Pentium_%28original%29
|Much faster floating-point unit. Some instructions showed an enormous
|improvement, most notably FMUL, with up to 15 times higher throughput
|than in the 80486 FPU.
|The Pentium is also able to execute a FXCH ST(x) instruction in parallel
|with an ordinary (arithmetical or load/store) FPU instruction.

Die FPU hat übrigens schon immer parallel zu den sonstigen Instruktionen gearbeitet!
Das ist quasi eine dritte Pipeline.

[Bonita Montero]

Wie hoch Latenz und Durchsatz sind.
Mit einem RISC-Backend ist's nur einfacher zu implementieren.

> Die FPU hat übrigens schon immer parallel zu den sonstigen Instruktionen
> gearbeitet!
> Das ist quasi eine dritte Pipeline.

Nein, das ist Quatsch. Die Instruktionen kommen bei aktuellen CPUs aus
der selbem Pipe, teilen sich dann aber in verschiedene Execution Units
entsprechend ihrer Abhängigkeiten.

[Helmut Schellong]

Ich könnte nun einen neuen sinnlosen Teil-Thread beginnen...
Das ist mir jedoch zu blöd.
Es ist, wie ich es sagte!

[Bonita Montero]

Am 19.06.2022 um 19:29 schrieb Helmut Schellong:

> Ich könnte nun einen neuen sinnlosen Teil-Thread beginnen...
> Das ist mir jedoch zu blöd.
> Es ist, wie ich es sagte!

Hier, sieht zunächst aus als hättest Du recht:
https://scr3.golem.de/screenshots/1907/Ryzen-3900X-3700X-Test/Ryzen-3000-Test-11.png
Wenn man sich aber das Frontend anschaut, dann sieht man, dass die
uOps erst ab dem Dispatch, also recht spät in der Pipe, getrennte
Wege gehen:
https://scr3.golem.de/screenshots/1907/Ryzen-3900X-3700X-Test/Ryzen-3000-Test-12.png

[Bonita Montero]

Achja: und Load-/Store-Unit teilen sich beide Zweige sowieso.