- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page