FLOAT_INVALID_OPERATION und FLOAT_OVERFLOW nur 64Bit

[venice2]

Gleiche Funktion in 32Bit und 64Bit

Delphi-Quellcode:

procedure TBassPlayer.XFFT(FR, FI: array of single; Sign, Sample, SampleCount: Integer);
// Wave Daten glätten
var
  Q, J, M, L, le, le1, ip: integer;
  tr, ti, s, ur, ur1, ui, wr, wi: single;

begin

    J := 1;
    for Q := Sample to SampleCount do
    begin
      if Q < J then
      begin
        s     := FR[Q];
        FR[Q] := FR[J];
        FR[J] := s;
        s     := FI[Q];
        FI[Q] := FI[J];
        FI[J] := s;
      end;

      M := ((SampleCount + 1) div 2);
      while M < J do
      begin
        J := J - M;
        M := M div 2;
      end;
      J := J + M;
    end;

    for L := 1 to 8 do
    begin
      le  := trunc(Power(2, L));
      le1 := le div 2;
      ur  := 1;
      ui  := 0;
      wr  := Cos(PI / le1);
      wi  := Sign * Sin(PI / le1);

      for J := 1 to le1 do
      begin
        Q := J;
        while Q <= (SampleCount + 1) do
        begin
          ip     := Q + (le1 - 1);
          tr     := FR[ip] * ur - FI[ip] * ui; // FLOAT_INVALID_OPERATION nur 64Bit
          ti     := FR[ip] * ui + FI[ip] * ur;
          FR[ip] := FR[Q] - tr;
          FI[ip] := FI[Q] - ti; // FLOAT_OVERFLOW nur 64Bit
          FR[Q]  := FR[Q] + tr;
          FI[Q]  := FI[Q] + ti;
          Q      := Q + le;
        end;

        ur1 := ur * wr - ui * wi;
        ui  := ur * wi + ui * wr;
        ur  := ur1;
      end;
    end;

    for Q := Sample to (SampleCount + 1) do
    begin
      FR[Q] := FR[Q] * DivN;
      FI[Q] := FI[Q] * DivN;
    end;
end;

Dies Funktion Arbeitet unter 32Bit so wie sie soll.
In 64Bit muß ich beide Fehler ignorieren.
Dort bekomme ich diese beiden Fehler! FLOAT_INVALID_OPERATION, FLOAT_OVERFLOW

Wieder irgend so ein Ding mit Daten Typen?

[himitsu]

Den Einzigen Typ-Unterschied gibt es beim Extended, welchen man eigentlich eh hätte nie direkt verwenden sollen.

Extended gibt es unter 64 Bit nicht, das ist dort bloß noch ein Alias für Double.


Aber eventuell sieht die Exception-Maske unterschiedlich aus?
FGetExceptMask
FSetExceptMask
[EDIT]
besser Folgenes verwenden
GetExceptionMask
SetExceptionMask
(welches unter 64 Bit auf GetSSEExceptionMask umgeleitet wird)
[/EDIT]

Zitat:

exInvalidOp - An invalid operation was attempted.
exDenormalized - A number was reduced in size smaller than can be stored as non-zero. It has been denormalized.
exZeroDivide - An attempt was made to divide by zero.
exOverflow - A number has exceeded the highest positive value supported.
exUnderflow - A number has exceeded the highest negative value supported.
exPrecision - A number has exceeded the number of digits of precision.

Aber wenn es daran liegt, dass unter 32 Bit einige Exception nicht ausgelöst werden, dann würde ich wohl eher nachsehn, warum es zum Überlauf kommt, also die Ursache beheben, anstatt nur an den Symptomen rumzupfuschen.


Single ist und bleibt auch unter 64 Bit Single
und Integer war mal als platformabhängiger Typ definiert (unter 16 Bit war er noch 16 Bit), aber für/vor 64 Bit wurde er auf 32 Bit eingefroren (von den CPU-Entwicklern und alle Softwaretools machten mit) und stattdessen ein neuer Typ erfunden (nennt sich in Delphi NativeInt),
also Integer (LongInt) bleibt auch unverändert.




[EDIT]
Unter 64 Bit dürften die Floats über SSE behandelt werden (GetMXCSR),
wärend es unter 32 Bit noch die FPU machte (Get8087CW).

[venice2]

Zitat:

Unter 64 Bit dürften die Floats über SSE behandelt werden,
wärend es unter 32 Bit noch die FPU machte.

Und wie soll ich das beheben?

Zitat:

Aber wenn es daran liegt, dass unter 32 Bit einige Exception nicht ausgelöst werden, dann würde ich wohl eher nachsehn, warum es zum Überlauf kommt, also die Ursache beheben, anstatt nur an den Symptomen rumzupfuschen.

Deshalb stelle ja ich die Frage hier!
Wie gesagt 32Bit macht keinen Ärger.

Im Moment habe ich nur die Möglichkeit diese Exzeption von der Anwendung auswerten zu lassen anstelle vom Debugger.
Denke das ist legitim sonst würde man diese Möglichkeit nicht anbieten oder?
Das ist doch kein Rumpfuschen.

[himitsu]

Zitat:

Wie gesagt 32Bit macht keinen Ärger.

* die Berechnungen ergeben dort keine Überläufe
* oder es gibt Überläufe, aber es werden keine Exceptions ausgelöst

Das muß erstmal eklärt werden. (darum eben mal schnell nachsehn, ob sich die Masken unterscheiden .... ich hab auch schon Fremdkompnenten gesehn, welche grob fahrlässig heimlich dauerhaft die Fehlermasken verändern)
Rein rechnerisch sollte FPU und SSE die gleichen Ergebnisse liefern, also dürfte es da eigentlich keinen (großen) Unterschied geben.
https://xem.github.io/minix86/manual...5b67a-276.html

"Damals" war die Floating Point Unit "8087" ein eigener Chip, neben der Central Processing Unit "8086" ... schon länger ist der Teil in die CPU integriert, ähnlich wie inzwischen oftmals auch GPU und andere "Chips".
Und nun hatte man sich halt gedacht diesen "alten" Teil mal zu ensorgen.

Zitat:

Das ist doch kein Rumpfuschen.

Es kommt drauf an.
* ist es vorgesehn, daß mit Überläufen "gerechnet" wird (z.B. bei Verschlüssels-Algorithmen oft gern ausgenutzt)
* sollte es eigentlich garkeine Überläufe geben, dann wäre es doch bissl blöd nur die "Fehlermeldung" abzuschalten, anstatt den eigentlichen Fehler zu beheben

[venice2]

Zitat:

* die Berechnungen ergeben dort keine Überläufe
* oder es gibt Überläufe, aber es werden keine Exceptions ausgelöst

Nun ja laut den Einstellungen müßte eigentlich ein Exception geworfen werden wenn eines Aufritt. Siehe Pic.
Aber es gibt keines.

Habe das hier mal getestet bringt aber keine Änderung

Delphi-Quellcode:

type
  TFPControlState = record
    _8087CW: Word;
    MXCSR: UInt32;
  end;

function GetFPControlState: TFPControlState;
begin
  Result._8087CW := Get8087CW;
  Result.MXCSR := GetMXCSR;
end;

procedure RestoreFPControlState(const State: TFPControlState);
begin
  Set8087CW(State._8087CW);
  SetMXCSR(State.MXCSR);
end;

var
  FPControlState: TFPControlState;
....
FPControlState := GetFPControlState;
try
  // call into external library that changes FP control state
finally
  RestoreFPControlState(FPControlState);
end;

Zitat:

sollte es eigentlich garkeine Überläufe geben, dann wäre es doch bissl blöd nur die "Fehlermeldung" abzuschalten, anstatt den eigentlichen Fehler zu beheben

Das ist korrekt.
Muß halt mal schauen wie ich das lösen kann.

[venice2]

Es geht nur Fehlerfrei mit Extended unter 64Bit
Auch wenn du sagst

Zitat:

welchen man eigentlich eh hätte nie direkt verwenden sollen.