inputting real10 floats

[raymond]

Thanks for all that additional info. I only treated the 80-bit data size because it was the only subject being in contention.

There is still the issue of initializing the x87 FPU to use 80 bit double extended precision
versus 64 bit double precision or 32 bit single precision.

The precision and the data sizes available for loading/storing are two absolutely different concepts which may be difficult to understand for newbies.

[GregL]

allynm,

Regarding the C Run-Time Library (CRT) functions mentioned in your original post, the CRT doesn't support the REAL10 data type.  It is due to Microsoft having to support a number of different hardware platforms and the REAL10 being specific to x86/x87, they decided not to support it.  :tdown  A bad decision in my opinion, some C compilers (i.e. Intel) do support it.

[jj2007]

allynm,

Regarding the C Run-Time Library (CRT) functions mentioned in your original post, the CRT doesn't support the REAL10 data type.  It is due to Microsoft having to support a number of different hardware platforms and the REAL10 being specific to x86/x87, they decided not to support it.  :tdown  A bad decision in my opinion, some C compilers (i.e. Intel) do support it.

If it's just for printing, and if you can afford a small loss in precision, just convert your REAL10, using either a temporary REAL8 in the .data? section or the stack:

Code Select Expand

include \masm32\include\masm32rt.inc

.data
MyReal10 REAL10 123.456

.data?
MyTmp8 REAL8 ?

.code

start:
fld MyReal10
fst MyTmp8
invoke crt_printf, chr$("%f"), MyTmp8

print chr$(13, 10, "Same with stack:", 13, 10)
sub esp, 8 ; create space on the stack
fst REAL8 ptr [esp]
invoke crt_printf, chr$("%f"), REAL8 ptr [esp]
add esp, 8
inkey chr$(13, 10, "Press any key")
exit
end start


Otherwise, use Str$ - it supports REAL10.

[GregL]

jj,

Yes, if it's just for printing, it (usually) doesn't matter.

[dedndave]

Jochen's Str$ works REAL good

[donkey]

Seems you don't understand what mean an internal use of real10 numbers.
You can't enter a number more than 8 bytes (a qword ) in the fpu.
A real10 number in your source code is of no use for the fpu.
Here is AMD64 reference book,better explain

x87 instructions operate on data in three floating-point formats—32-bit single-precision, 64-bit
double-precision, and 80-bit double-extended-precision (sometimes called extended precision)—as
well as integer, and 80-bit packed-BCD formats.
x87 instructions carry out all computations using the 80-bit double-extended-precision format. When
an x87 instruction reads a number from memory in 80-bit double-extended-precision format, the
number can be used directly in computations, without conversion. When an x87 instruction reads a
number in a format other than double-extended-precision format, the processor first converts the
number into double-extended-precision format. The processor can convert numbers back to specific
formats, or leave them in double-extended-precision format when writing them to memory.
Most x87 operations for addition, subtraction, multiplication, and division specify two source
operands, the first of which is replaced by the result. Instructions for subtraction and division have
reverse forms which swap the ordering of operand

Are you saying that you cannot move an Extended Precision number from memory to the FPU, if that's your claim then its incorrect. The FPU accepts REAL10 operands and loads them at the correct precision, that is there is no down-conversion to REAL8 then internal up-conversion back to REAL10. Even the reference you quoted says that the FPU can use REAL10 directly:

When an x87 instruction reads a number from memory in 80-bit double-extended-precision format, the number can be used directly in computations, without conversion.

Perhaps I misunderstood your post.

Edgar

[jj2007]

Seems you don't understand what mean an internal use of real10 numbers.
You can't enter a number more than 8 bytes (a qword ) in the fpu.
A real10 number in your source code is of no use for the fpu.

Yves,
As Raymond, Michael and dsouza have already stated, the FPU does support REAL10 in the source. The limits of precision have extensively been discussed in the multiplier table thread, which served as input to the Str$ algo. The latter accepts Real10 as input.

You might be confused by the fact that at program start the FPU is set to 53 bits precision, which corresponds to a REAL8. This can be changed by a simple finit, though.

[GregL]

You might be confused by the fact that at program start the FPU is set to 53 bits precision, which corresponds to a REAL8. This can be changed by a simple finit, though.

And it's Windows that sets the FPU to 53-bits precision.

[jj2007]

You might be confused by the fact that at program start the FPU is set to 53 bits precision, which corresponds to a REAL8. This can be changed by a simple finit, though.

And it's Windows that sets the FPU to 53-bits precision.

Yes, that's a pretty stupid default behaviour. In Str$, I chose to stay on the safe side and save/restore the current settings:

Code Select Expand

fstcw f2sConWold ; status word could be saved as fstsw ax,
mov eax, dword ptr f2sConWold ; but no such instruction for Control word
or ax, 011100000000b ; rounding mode DOWN,
mov dword ptr f2sConW, eax ; precision max=64
fldcw f2sConW ; set new control word
....
fldcw f2sConWold ; restore control word



[dedndave]

would have been so much simpler if they just did an FINIT before handing it over to your process
there they go, thinking again

[Astro]

...if they don't bother to set it up when they hand over control, can you break something if you don't set it back as it was??  :eek  I guess I'll find out soon enough...

Best regards,
Astro.

[dedndave]

well - that has been the subject of some discussion
it appears that a process gets a clean slate and cannot screw things up for another process or thread
i am not so sure about exceptions - if an exception has occured, i don't know if it can be saved
Raymond is the guy to ask about that

[raymond]

You can set up the FPU any way you want. It's yours to do whatever you need.

If you mess up the FPU, the only harm that could happen is to yourself. NO OTHER PROCESS can get affected, not even Windows or any other OS.

HOWEVER, Windows can mess it up for you if you leave some data in its registers and you call some of the APIs which use MMX instructions to compute anything (even simple things such as 2+2), the more notorious ones being those displaying a dialog box.