Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28510 Discussions

Intel's Position on x87 for the Future

rokelley
New Contributor I
754 Views

We've used the /arch:ia32 option to build 32-bit apps to x86/x87 in the past so that some operations would be carried out in the 80-bit ST registers (et al.). Moving to ifx and 64-bit builds, it seems that this is now either deprecated, difficult, or impossible. We're wondering what Intel's position on this is: should we use quad precision for these operations? Will it still be/is it now possible to generate x87 code from ifx targeting intel64?

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
732 Views

No - ifx does not and will not generate IA-32 code, including x87. If you are still targeting IA-32 you will need to continue using ifort. My advice would be to rework your application so that it does not depend on x87.

View solution in original post

0 Kudos
5 Replies
Steve_Lionel
Honored Contributor III
733 Views

No - ifx does not and will not generate IA-32 code, including x87. If you are still targeting IA-32 you will need to continue using ifort. My advice would be to rework your application so that it does not depend on x87.

0 Kudos
jimdempseyatthecove
Honored Contributor III
731 Views

>>should we use quad precision for these operations? 

Yes, this will be portable, and when the CPU supports quad precision instructions (and compiler implements the instructions), you will have no future coding changes.

Jim Dempsey

 

JohnNichols
Valued Contributor III
714 Views
7ffe ffff ffff ffff ffff ffff ffff ffff16 = 216383 × (2 − 2−112)
                                          ≈ 1.1897314953572317650857593266280070162 × 104932
                                            (largest normal number)

What are we going to do with such numbers.  

If it is the width of the universe then we are measuring in such small units we cannot draw them in reality.  

I had to explain to someone the chance that an event of E-205 occurred, that is like coating the outside of the universe in protons and numbering them and Jim and I simultaneously pick the same proton.  There are not enough protons to do that.  

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
697 Views

John,

The utility of quad precision is not necessarily limited to the magnitude or 1/magnitude of real(16).

As an example, (you are familiar with bridge construction), consider a large bridge, say on the order of Golden Gate Bridge. Assume you need to simulate, or study, strain-rates of the main suspension cable against the strain-rates of the end-point connectors. The magnitude difference in the length of the suspension cable and the connector might be on the order of 10,000 to 1. Computations of interactions between items could produce an error in four significant places when the strain = 100% of the smaller item. If looking at a strain of 1% this is an error in six significant places, etc...

 

While there are computational methods to handle this scenario (and I use them), not paying attention to this in your coding can come back and bite you in strange ways.

In the simulation I am working on now (Space Elevator), my equivalent to the suspension cable is on the order of 100,000 x that of the Golden Gate Bridge. So my comparative size differences are on the order of 500,000,000 : 1 and strain difference of tiny fractions of the lessor lengths fall off the precision of the larger lengths.

 

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
675 Views

Jim:

I understand the utility of quad values,  and modelling large components attached to small things is never fun.  

bearings on a bridge are one example. 

0 Kudos
Reply