Parameter in FPU laden (Assembler)

[himitsu]

Zitat von Klaus01:

Ja, Dein Code compiliert bei mir auch nur mit Windows 32.

Richtig, weil es dort keine FPU gibt.

OK, die FPU als EinzelChip gibt es schon ewig nicht mehr, aber als LogicEinheit war Sie in der CPU (32 Bit) dennoch integriert.
Unter 64 Bit macht das Mathematische die CPU nun selbst.

[markus888]

Zitat von himitsu:

Unter 64 Bit macht das Mathematische die CPU nun selbst.

Also ist das im 32 Bit Modus dann nur eine Simulation?
Grundsätzlich kann man ja Werte in die FPU laden, wie man beim Debuggen sehen kann - was bedeutet das dann?
Immerhin nutzt die FPU 80Bit und simd Register meines wissens nur 64.
Die Aussage erscheint mir daher seltsam.

Hast du zufällig einen Link zu einer Doku bezüglich 64 Bit mit FPU?

Edit:
@himitsu, ich glaube du verwechselst da was. Die Befehle die du meinst haben mit 64 Bit nichts zu tun und können im 32 Bit Modus genauso genutzt werden.

[HintByError]

Die FPU-Instruktionen sollen im 64-Bitmodus nicht mehr verwendet werden. Die im 64-Bit-Modus vorhandene FPU ist nur für die Umstellung von FPU-Code, der in 32-Bit-Assembler geschrieben wurde, in den 64-Bit-Modus vorhanden.

Zitat:

FPU instructions
The x87* ‬FPU instructions are executed by the so-called "math coprocessor"‬.* ‬These instructions operate on floating-point,* integer,* ‬and binary-coded decimal (BCD) ‬operands.* The main purpose of these instructions are to perform floating-point arithmetic.* ‬But nowadays we have SIMD instructions that are much faster than FPU.* ‬So,* please,* don't use the FPU in newly written code,* because it usage is marked as outdated in Linux ‬64* ‬ABI.* ‬Use SIMD instead.

Quelle: https://linasm.sourceforge.net/docs/...ions/index.php

Soweit ich das vor Jahren ausgetestet habe, ist die Umsetzung der FPU-Instruktionen im 64-Bit-Modus im Detail nicht identisch mit der Umsetzung im 32-Bit-Modus. Da liegen dann die Tücken bei der Verwendung der FPU-Instruktionen im 64-Bit-Modus verborgen.

[himitsu]

Nicht direkt "simulation" ... die FPU ist aktuell einfach nur direkt in der CPU eingebaut. (sie ist aber nur mit dem 32 Bit-System verdrahtet, bzw. es könnte auch sein, dass es sie oftmals garnicht mehr gibt und ihre Register/ControlCodes z.B. ans SSE umgeleitet werden, aber egal)

(so wie heute oftmals auch gleich die Nouthbridge, Southbridge, IO-Controller, GPU/GrafikKarte, SoundKarte, SATA-Controller, LAN-Controller, USB-Controller, Caches uvm. direkt im CPU-Chip integriert sind)



Beim Design der 64 Bit Architektur hat man aber so Einiges verändert und Fließkommazahlen werden nicht mehr über die FPU (floating point processing unit) berechnet.
Schon für 32 Bit gab es mit der Zeit immer mehrer Erweiterungen, z.B. MMX/SSE.
In 64 Bit wird nur noch mit den SSE-Registern gerechnet und die alten ST-Register der FPU gibt es nicht mehr und entsprechend haben sich auch die Befehlssätze verändert.

[markus888]

Zitat von HintByError:

Soweit ich das vor Jahren ausgetestet habe, ist die Umsetzung der FPU-Instruktionen im 64-Bit-Modus im Detail nicht identisch mit der Umsetzung im 32-Bit-Modus.

Hallo Wolfgang,
grundsätzlich habe ich mich mit der FPU nicht im Detail beschäftigt.
Aber meines Wissens kann man das Verhalten der FPU steuern.
Hast du dich da diesbezüglich mal vertieft?

Bei Berechnungen hast du mit der FPU jedenfalls eine massiven Vorteil was die Genauigkeit betrifft.

Interessant finde ich die Aussage mit der Geschwindigkeit.
Mal sehen was die Tests sagen.

Ich werde das aus gegebenem Anlass testen.
Mir gehts grade um die Performance bei compare für Gleitkommazahlen und da spielt die Genauigkeit nun mal keine Rolle.
Da die Befehle ja auch alle in der 32 Bit Simulation unterstützt werden, kann man die ja immer einsetzen.



Danke jedenfalls für den Hinweis.

[markus888]

Zitat von markus888:

Mal sehen was die Tests sagen.

Also die SSE Anweisung ist bei meinem Testrechner beim Vergleich der Gleitkommazahl etwa 50% schneller wie die FPU.

Das passt natürlich perfekt.

[markus888]

Zitat von himitsu:

In 64 Bit wird nur noch mit den SSE-Registern gerechnet und die alten ST-Register der FPU gibt es nicht mehr und entsprechend haben sich auch die Befehlssätze verändert.

Also habs jetzt aufgrund deiner Aussage getestet.
64 Bit Anwendung, da funktioniert in der FPU alles ganz normal.
Und natürlich sind die ST Register alle vorhanden.
Vielleicht ist es ja CPU abhängig, aber mich wundern diese ganzen Aussagen schon.
Schau einfach mal bei deinem Rechner nach.

Hab Logarithmus und Multiplikation mit asm Anweisungen getestet.
Mach mal Logarithmus in Delphi und schau mal was die CPU da macht.
Das sind mehrere hundert Anweisungen mit Objekten mit x Speicherfreigaben erforderlich.
Da schaut mal blöd was da passiert.

Aber von der Hardwareentwicklung habe ich keine Ahnung.
Kann nur beurteilen was ich sehe.
LG Markus

[mwilms]

Vielen Dank für Eure Beiträge.
Scheinbar ist meine Programmierweise der FPU etwas antiquiert
Wäre aber mal interessant zu wissen, was die übliche FPU Programmierung in Delphi unter Windows64 verhindert.
Aus meiner Sicht wäre das doch möglich, oder?

[himitsu]

Zitat von mwilms:

Wäre aber mal interessant zu wissen, was die übliche FPU Programmierung in Delphi unter Windows64 verhindert.

Das var .

Nur für Win32 kann Delphi noch sehr viel, sogar Inline-Assembler. (alles, was vor Embarcadero mal gebaut wurde)
Ansonsten kann Delphi entweder kein Assembler, oder z.B. für Win64 ausschließlich "komplette" Assembler-Methoden. (Funktions-Header und sonst nichts außer asm ... end; , also lokale Variablen im Assembler -> Register bzw. manuell auf den Stack)

lokale Variablen würden zusätzlichen Code für Erstellung und Freigabe bedeuten.

[mwilms]

Bin auch auf folgende Lösung gekommen:

Delphi-Quellcode:

procedure TestParm(A: double);
var
  B: double;
asm
  movsd B,XMM0
  FLD B
end;

Aber in der Registeransicht der FPU Register erscheint der Wert merkwürdigerweise nicht ?!