Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/Compiler/Delphi    [ Add a report in this area ]  
Report #:  92342   Status: Open
Extended should remain an 80-bit type on 64-bit platforms
Project:  Delphi Build #:  16.0.4256.43595
Version:    16.0 Submitted By:   Jan Goyvaerts
Report Type:  Basic functionality failure Date Reported:  3/16/2011 11:26:08 PM
Severity:    Serious / Highly visible problem Last Updated: 2/7/2014 10:41:19 PM
Platform:    All versions Internal Tracking #:   282292
Resolution: None (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (8 Total Ratings)
4.75 out of 5
Total Votes: 196
Description
Embarcadero has stated in their public roadmaps that they are working on a 64-bit Delphi compiler.  Allen Bauer has tweeted at http://twitter.com/kylix_rd/status/28836216598 and http://twitter.com/kylix_rd/status/28916374239 that in 64-bit Delphi, the Extended type may be identical to the Double type, reducing it from an 80-bit floating point type to a 64-bit floating point type.

In my opinion this is a very bad idea.  The precision of my application's arithmetic should not change depending on which CPU I am compiling it for.  My application's precision certainly should not reduce when migrating to a platform that has more bits.

Changing the bitness of Extended is inconsistent with not changing the bitness of any other types such as Integer, as Allen Bauer indicates at http://twitter.com/kylix_rd/status/28804245235

The fact that 80-bit floating point may be suboptimal for parameter passing or even slower to compute because the underlying hardware is optimized for 64-bit floating point is not a reason to force 64-bit floating point onto developers.  Developers should be able to choose whether they want 80-bit precision or 64-bit speed.

To this date Delphi XE still supports the Real48 type.  This is a 48-bit floating point type.  The x86 platform, which is the only platform that Delphi XE supports, has no hardware support for 48-bit floating point.  Yet Delphi XE supports this type, purely for backwards compatibility with the Real type in old Pascal compilers that did 48-bit floating point in software.

Since the x87 FPU is available on the x64 platform, I would expect a 64-bit Delphi compiler to fully support Extended as an 80-bit type, even if that code won't run at optimal speeds due to the x64 platform being optimized for 64-bit quantities.  It should be my choice whether to use 80-bit Extended or 64-bit Double with 64-bit Delphi, just like it is my choice today whether I want 48-bit Real48 or 32-bit Single or 64-bit Double.

If a platform does not support 80-bit floating point at all, then the Extended type should be undefined instead of silently downgrading everything to 64-bit floating point.  If some programmers do want Extended to be 64 bits on such platforms, they can easily add "type Extended = Double;" in their own source code.

If Embarcadero does produce a Delphi compiler that does not support Extended at all, then on the other platforms the Extended type should be marked with the "platform" directive or something similar to alert to the fact that Extended only works on some platforms.

I've been developing with Turbo Pascal and Delphi long enough to remember the shift from 16 bit to 32 bit when Integer suddenly changed from 16 bits to 32 bits.  This caused all kinds of complications.  So I think it's the right choice to keep Integer as 32 bits when moving to a 64-bit platform.  I want the same for the floating point types.
Steps to Reproduce:
None
Workarounds
None
Attachment
None
Comments

Uwe Raabe at 3/20/2011 5:18:01 AM -
This would be a showstopper for my biggest application (CAM) that relies heavily on precise geometrical calculations. As a result I would have to write a converter for the existing file format (which then has to be 32 bit
and thus cannot be part of the x64-exe) and reevaluate and test all of the constants that rely on the extended precision. It may render the port to x64 as not worth the effort. Given that CAM is one of the app types that could really benefit from 64 bit memory this simply doesn't sound right. The least I expect is to be able to read streams  in x64 that were written in x32.

BTW, the geometric kernel development started under Turbo Pascal 3 about 25 years ago. As a CAD shop all of our customers used to have a coprocessor at that time. The source survived every port to a new version up to Delphi XE. With the speed of any new CPU and the increasing amount of memory available it gained a lot of functionality up to now. It would be a pity if this were stopped with x64.

Gerd Thieme at 4/23/2011 4:57:20 AM -
I think you are right.

Extended is the native floatimg point type with current CPUs. Except for SIMD instructions, nearly all floating-point computation is done in this native type and then takes an additional amount of time for rounding it to single or double precision, if ever (as a remarkable exception from this rule, FDIV and FSQRT are fastest with single precision results).

Possibly, 80-bit floats have to be replaced by coming 128-bit floats in some future, or by new 144-bit extended floats which may come in two different, mutually incompatible formats (binary and decimal).

Not before these types are available in hardware, one should think of removing 80-bit extendeds or, preferably, emulating them in software like the ancient 48-bit reals.

Server Response from: ETNACODE01