10

What should we expect from the floating point support in 64-bit Delphi compiler?

  • Will 64-bit compiler use SSE to implement floating point arithmetic?

  • Will 64-bit compiler support the current 80-bit floating type (Extended)?

These questions are closely related, so I ask them as a single question.

kludg
  • 27,213
  • 5
  • 67
  • 118
  • I know I have read about this, but do not really remember where. – Andreas Rejbrand Oct 31 '10 at 17:30
  • possible duplicate of [How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler?](http://stackoverflow.com/questions/4051603/how-should-i-prepare-my-32-bit-delphi-programs-for-an-eventual-64-bit-compiler) – Gregor Brandt Oct 31 '10 at 19:30
  • 3
    @gbrandt: So *every* new question concerning Delphi 64-bit should be closed as an exact duplicate? – Andreas Rejbrand Oct 31 '10 at 21:19
  • 1
    I must say that if support for 80-bit floating point values were dropped, that would be VERY bad news for me. And it might cause all sorts of headaches for people even if they don't actually need this precision because programs (numerical results) might behave differently among 32-bit and 64-bit programs. – PhiS Nov 01 '10 at 11:48

6 Answers6

5

I made two posts on the subject (here and there), to summarize, yes, the 64bit compiler uses SSE2 (double precision), but it doesn't use SSE (single precision). Everything is converted to double precision floats, and computed using SSE2 (edit: however there is an option to control that)

This means f.i. that if Maths on double precision floats is fast, maths on single precision is slow (lots of redundant conversions between single and double precisions are thrown in), "Extended" is aliased to "Double", and intermediate computations precision is limited to double precision.

Edit: There was an undocumented (at the time) directive that controls SSE code generation, {$EXCESSPRECISION OFF} activates SSE code generation, which brings back performance within expectations.

Eric Grange
  • 5,931
  • 1
  • 39
  • 61
3

According to Marco van de Voort in his answer to: How should I prepare my 32-bit Delphi programs for an eventual 64-bit compiler:

x87 FPU is deprecated on x64, and in general SSE2 will be used for florating point. so floating point and its exception handling might work slightly differently, and extended might not be 80-bit (but 64-bit or, less likely 128-bit). This also relates to the usual rounding (copro controlwork) changes when interfacing wiht C code that expects a different fpu word.

PHis commented on that answer with:

I wouldn't say that the x87 FPU is deprecated, but it is certainly the case that Microsoft have decided to do their best to make it that way (and they really don't seem to like 80-bit FP values), although it is clearly technically possible to use the FPU/80-bit floats on Win64.

Community
  • 1
  • 1
lkessler
  • 19,819
  • 36
  • 132
  • 203
  • FPU was deprecated by MS on x86_64 initially (XP64), and afaik its context was not even saved in initial XP64 versions. This was remedied later, but it is still deprecated. – Marco van de Voort Oct 31 '10 at 19:42
  • @Marco - note however that some compilers (e.g. Intel's C++ compiler) can produce code for the x87 FPU on x64. Also Microsoft's Macro Assembler for 64-bit does support the FPU instruction set. So it seems to be more of an issue that Microsoft don't want x87 code if they can avoid it (e.g. VC++) but the OS does support it. – PhiS Nov 01 '10 at 11:40
  • It's afaik deprecated in the x86_64 api. Probably scheduled to be retired when 32-bit OSes (and apps?) are really toast. – Marco van de Voort Nov 01 '10 at 17:23
  • @Marco - Hmm, I am skeptical; we'll see. Is there actually any case where the Win32 API uses 80-bit floats (discounting return values in ST(0) which are whatever you want them to be)? If not, then the same API obviously has no need to be bothered with the x87 FPU on x64, where you have at least SSE2. (But that doesn't mean a program can't use x87 internally.) – PhiS Nov 01 '10 at 18:38
  • Afaik no, since Windows NT was meant to be portable and supported other targets (sparc,powerpc and IA64) that didn't support extended. – Marco van de Voort Dec 30 '11 at 14:47
3

I just posted an answer to your other question, but I guess it actually should go here:

Obviously, nobody except for Embarcadero can answer this for sure before the product is released.

It is very likely that any decent x64 compiler will use the SSE2 instruction set as a baseline and therefore attempt to do as much floating point computation using SSE features as possible, minimising the use of the x87 FPU. However, it should also be said that there is no technical reason that would prevent the use of the x87 FPU in x64 application code (despite rumours to the contrary which have been around for some time; if you want more info on that point, please have a look at Agner Fog's Calling Convention Manual, specifically chapter 6.1 "Can floating point registers be used in 64-bit Windows?").

Edit 1: Delphi XE2 Win64 indeed does not support 80-bit floating-point calculations out of the box (see e.g. discussuion here (although it allows one to read/write such values). One can bring such capabilities back to Delphi Win64 using a record + class operators, as is done in this TExtendedX87 type (although caveats apply).

PhiS
  • 4,540
  • 25
  • 35
2

For the double=extended bit:

Read ALlen Bauer's Twitter account Kylix_rd:

http://twitter.com/kylix_rd

In hindsight logical, because while SSE2 regs are 128 bit, they are used as two 64-bit doubles.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89
  • But it's the same as with other types that don't fit registers: the calling convention allows them to be passed by reference – PhiS Nov 01 '10 at 12:03
  • Integers commonly have one type with higher precision than the ALU has. (32-bit -> int64, 64-bit -> int128), this has to do with certain properties of integers. However this is usually not the case for floating point. The x87 CPU supports extended as highest level, but Delphi doesn't support anything more. While passing by reference (e.g. as record with two doubles) works, that only solves pumping the data. Not do calculations, which will be soft float and very slow. Keep in mind Int64 is partially CPU accelerated – Marco van de Voort Dec 30 '11 at 14:44
2

We won't know for sure how the 64-bit Delphi compiler will implement floating point arithmetic until Embarcadero actually ships it. Anything prior to that is just speculation. But once we know for sure it'll be too late to do anything about it.

Allen Bauer's tweets do seem to indicate that they'll use SSE2 and that the Extended type may be reduced to 64 bits instead of 80 bits. I think that would be a bad idea, for a variety of reasons. I've written up my thoughts in a QualityCentral report Extended should remain an 80-bit type on 64-bit platforms

If you don't want your code to drop from 80-bit precision to 64-bit precision when you move to 64-bit Delphi, click on the QualityCentral link and vote for my report. The more votes, the more likely Embarcadero will listen. If they do use SSE2 for 64-bit floating point, which makes sense, then adding 80-bit floating point using the FPU will be extra work for Embarcadero. I doubt they'll do that work unless a lot of developers ask for it.

Jan Goyvaerts
  • 21,379
  • 7
  • 60
  • 72
1

If you really need it, then you can use the TExtendedX87 unit by Philipp M. Schlüter (PhiS on SO) as mentioned in this Embarcadero forum thread.

@PhiS: when you update your answer with the info from mine, I'll remove mine.

Community
  • 1
  • 1
Jeroen Wiert Pluimers
  • 23,965
  • 9
  • 74
  • 154