Recent

Author Topic: [solved] tiny differences with StrToFloat  (Read 4615 times)

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: tiny differences with StrToFloat
« Reply #15 on: May 21, 2020, 06:39:55 pm »
At least one official Microsoft page explicitly mentions that the x87 is deprecated on Win64: https://docs.microsoft.com/en-us/windows/win32/dxtecharts/sixty-four-bit-programming-for-game-developers
Quote
The x87, MMX, and 3DNow! instruction sets are deprecated in 64-bit modes. The instructions sets are still present for backward compatibility for 32-bit mode; however, to avoid compatibility issues in the future, their use in current and future projects is discouraged.

nanobit

  • Full Member
  • ***
  • Posts: 160
Re: tiny differences with StrToFloat
« Reply #16 on: May 21, 2020, 06:45:06 pm »
Jonas, your Assembly Code paragraph refers to MS compilers.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 1058
Re: tiny differences with StrToFloat
« Reply #17 on: May 21, 2020, 06:49:44 pm »
"The instructions sets are still present for backward compatibility for 32-bit mode" makes no sense in the context of a (64 bit) compiler. This is about operating system (and possibly cpu) support.

nanobit

  • Full Member
  • ***
  • Posts: 160
Re: tiny differences with StrToFloat
« Reply #18 on: May 23, 2020, 07:19:06 am »
Instructions need support from MS dev tools (in context of article), operating system and hardware.
One could speculate whether the paragraph was written before Win ABI docs
became stable about x87, but this does not really matter at the end.

The support by the operating system is specified in the current Win ABI.
The support of hardware FPU will not disappear before emulators step in.
That's enough to make decisions.


Thaddy

  • Hero Member
  • *****
  • Posts: 14203
  • Probably until I exterminate Putin.
Re: tiny differences with StrToFloat
« Reply #19 on: May 23, 2020, 07:48:26 am »
One could speculate whether the paragraph was written before Win ABI docs
became stable about x87, but this does not really matter at the end.
On the contrary: it is essential. And the win64 ABI is fully documented and not an article.
I would focus on the fact that x87 registers and mmx overlap....and mmx is at most 64 bit. (not to be confused with later additions like SSE family)
https://en.wikipedia.org/wiki/MMX_(instruction_set)
« Last Edit: May 23, 2020, 08:00:45 am by Thaddy »
Specialize a type, not a var.

kegge13

  • New Member
  • *
  • Posts: 45
    • the BistroMath project
Re: tiny differences with StrToFloat
« Reply #20 on: May 24, 2020, 11:41:12 pm »
Thank all you hero members for the valuable input. I found the needle in an adjacent haystack.
In pseudo code my moving filter looks something like this:
Code: Pascal  [Select][+][-]
  1. if Abs(Pos[P1]-Pos[c])>L then
  2.   AddData(Pos[P1],Signal[P1]);
  3. if Abs(Pos[P2]-Pos[c])<=L then
  4.   AddData(Pos[P2],Signal[P2]);
where array Pos, Signal and L are 80 bit Extended in Delphi7.
On one of my test data sets the value of L happens to be a multiple of the stepsize (in general there is no constant stepsize). Therefore  Abs(Pos[P1]-Pos[c]) can be exactly L. Again, this is no problem in D7.
However in  64 bit Doubles the positions deviate slightly around the intended value (i.e string '9.1' becomes 9.09999...). Therefore the number of points in the filter changes randomly, giving noticable effects in the end.

My new code looks something like:
Code: Pascal  [Select][+][-]
  1. if Abs(Round(1000*(Pos[P1]-Pos[c])))>kL then
  2.   AddData(Pos[P1],Signal[P1]);
  3. if Abs(Round(1000*(Pos[P2]-Pos[c])))<=kL then
  4.   AddData(Pos[P2],Signal[P2]);

where integer kL:= Round(1000);

The multiplication with 1000 suits for my type of data but is rather arbitrary.

The second order polynomal filter indeed degrades slightly with 64 bit Doubles for internal data but this certainly has not a magnitude of multiple orders in the data. So this degradation stays invisible on the level of my data.

Some history: in the eighties I had the second desktop with a 80387 coprocessor at the former Philips physics labs, so I grew up with this kind of hardware. Why is this abandoned? Once I wrote one line of Pascal in assembler for speed reasons. Now there appear to be a lot of undocumented registers for unclear reasons. Then why not maintain the 80 bits cpu facilties?

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: tiny differences with StrToFloat
« Reply #21 on: May 25, 2020, 09:51:27 am »
Some history: in the eighties I had the second desktop with a 80387 coprocessor at the former Philips physics labs, so I grew up with this kind of hardware. Why is this abandoned? Once I wrote one line of Pascal in assembler for speed reasons. Now there appear to be a lot of undocumented registers for unclear reasons. Then why not maintain the 80 bits cpu facilties?

Because due to the history the x87 coprocessor still works in an asynchronous way (exceptions are only reported upon executing the next floating point instruction, which can be far away) and you can only work an a single value. With modern SIMD instructions you can do calculations on multiple values at once (SIMD = Single Instruction Multiple Data) and exceptions are reported right away. Also why do you say that there are a lot of undocumented registers? The instruction set including SSE is fully documented.

kegge13

  • New Member
  • *
  • Posts: 45
    • the BistroMath project
Re: tiny differences with StrToFloat
« Reply #22 on: May 25, 2020, 11:06:32 pm »
Because due to the history the x87 coprocessor still works in an asynchronous way (exceptions are only reported upon executing the next floating point instruction, which can be far away) and you can only work an a single value. With modern SIMD instructions you can do calculations on multiple values at once (SIMD = Single Instruction Multiple Data) and exceptions are reported right away. Also why do you say that there are a lot of undocumented registers? The instruction set including SSE is fully documented.

Thank you PascalDragon for your remarks. My (computational) problems are not large enough to go into parallel programming, but it is a nice thought anyway. The "unknown" registers were mentioned in a paper on speculative cpu cache reading strategies to get information from other processes. The author claimed that there were many registers (up to 150 or so) with unknown use or application. It is not at all my comptence area though. I was just interested in how these leakage strategies work. Also I do not remember the specific cpu type.

 

TinyPortal © 2005-2018