Although this might not be suitable for mainstream (desktop) computing, it would be suitable for premium priced products. Intel does have premium priced product lines e.g. mmm Extreme. You could lable it at mmm Extreme+ and double the price.
Emulation of the format will be much slower than inclusion of the 16-byte format in the SSE instruction set.
SSE has almost all the functionality to perform the 16-byte IEEE FPmath functions. SSE has 16 byte data path and 16 byte manipulation instructions but not the entire set necessary to efficiently implement real(16) math. The inclusion of the 16-byte format could potentially be done with a firmware change inside the processor without requiring a change in the design of the data paths. With the current SSE instruction set it is inefficient to perform 128 bit (112 bit) shifts and rotates. Note, the change would require no change in operating system to support the instruction extension. As an interrum measure, 16-byte integer math could be implemented. This would eliminate the bit barrier between the double quads.
Why would you want support for this anyway? A 64-bit double is accurate enough to measure the height of a mountain in nanometers, from the center of the earth! By the way, x87 actually does support a more accurate format, namely 80-bit extenced precision or long doubles. I would use either that or emulation, before expecting Intel to make the tradeoffs for a hardware implementation.
Although supporting full 128-bit FP may require excessive changes, supporting a few additional128-bit integer math functions might be incorporated without much extra effort. In particular you would like to be able to align the mantissas of two operands in preparation for addition. i.e. perform bit shift between 0 and 112 times in one instruction and inserting the implicit 1 and sign extension. The 128-bit add or subtract could then be performed. Then a normalize instruction to produce a delta exponent for incorporation into the prior saved exponent.
Accelerate most of the integer portion of an ADD/SUB. The biggest portion of the emulation using eax/rax... registersis in the rotation for the alignment. MUL and DIV would still loop 112 times but each iteration would consume significantly fewer instructioncycles. With a few number of extensions you could get considerable amount of performance boost. The thing to do would be to look at the source code of the REAL(16) math support routines and see what you need to give them a boost.
This is not important enough to me to bug Intel on this as I can mostly get by using REAL(8). In some of my simulation work I have to augment the position information with a floating reference point. e.g. Using a coarse position with respect to solar system barycenter then index using a finer position/velocity... of of that. Then occasionally perform reconciliations as the object of interest and moving reference point separate.
As an example, Pluto has a Aphelion orbital distance of 4,583,200,123 miles, or 24,199,296,649,440 feet. The dynamic range in feet would be approximately be twice this. If we consider the precision of a real(8) at 53 bits this means on the scale of the maximum dynamic range the precision reduces to an accuracy of ~0.005 feet. For planetary objects the precision is sufficient. However, when dealing with uncertainties of +/-0.005 feet the dynamics of lesser sized objects (e.g.artificial satellite)becomes problematic. As stated in the prior paragraph, the technique used to mitigate dynamics problems was to use a floating reference point.
Anyway, you can already do 128-bit shifts in a single instruction with SHRD and SHLD in x86-64. Adding and subtracting can be done with ADC and SBB in two instructions. 128-bit multiplication can be done with four 64-bit multiplications, and division is probably best done using the Newton-Raphson method (starting from a 64-bit division you can double the number of accurate bits in just one iteration). So everything you need to emulate it reasonably efficiently is already there I believe.
>>Oh, and in the civilized world we measure in metric SI units, not body parts.
The civilized world is using a measurement that is known to be in error. The meter was defined before it was measured. The definition was 1/10,000,000 the length of a meridian from the North Pole to the equator. The French made a measurement of part of a meridian (that went through Paris) and estimated the remainder. The French got this number wrong, but didn't notice this until after a "standard measure" bar of platinum was produced. This "standard measure" bar is short about 0.2mm.
Meters or feet makes little difference, about 1.5 bits of precision. When you are handling small differences in large values the number of bits in the calculation is important. Although you can perform some mathematical gymnastics using floating/moving reference points, sometimes you stumble and the errors are harder to detect.
For illustrative purposes, if the 1790's French were to build a cannon to fire a cannon ball around the Earth (neglecting Coriolis effect) their cannon ball would fall short ~8,000 meters.
That's only an error if you use the Meridional definition, which was only the standard from 1791 till 1795. After that the reference bar itself was the definition.
Feet was in practice still measured in body parts at that time, and later too. There were also tens of different highly inaccurate references in various countries. Thomas Jefferson proposed an (again, inaccurate) definition based on a pendulum, but it never even got legislated. Doing any sort of accurate scientific workin feetwas ridiculous. It only became somewhat usable after 1958when it wasdefined in terms of the meter.
Anyway, I never intended to turn this into a metric versus imerial discussion (since there really is no discussion). I was just surprised to see a scientist use miles and feet.
Aremy suggestions for 128-bit arithmetic useful to you for efficient emulation or do you require even higher performance?
>>Aremy suggestions for 128-bit arithmetic useful to you for efficient emulation or do you require even higher performance?
All I am saying is the same arguments against supporting REAL(16) can be applied against supporting REAL(8). And then degrade the argument to REAL(4). Note, many of the GPU's, until recently, supported only REAL(4). It was pressure by those using GPUs for numerical intensive applications that drove the GPU vendors into supporting REAL(8). I am just a squeaky wheel.