The MASM Forum

General => The Laboratory => Topic started by: Gunther on April 07, 2013, 02:10:07 AM

Title: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 02:10:07 AM
Here is the appropriate 32 bit source from the thread (http://masm32.com/board/index.php?topic=1767.0) inside the 64 Bit Assembler forum. There are no differences in the C++ source, but a few differences inside the assembly language source.

Gunther
Title: Re: Dealing with REAL10 values
Post by: MichaelW on April 07, 2013, 02:01:02 AM
I don’t have time ATM to examine this further, but on my XP system with a recent MinGW installation the 32-bit LongDouble.exe triggers an access violation exception in libstdc++-6!ZSt4cout. Here are the dependencies as returned by Dependency Walker:

KERNEL32.DLL
LIBGCC_S_DW2-1.DLL
LIBSTDC++-6.DLL
LONGDOUBLE.EXE
MSVCRT.DLL
NTDLL.DLL

Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 02:18:48 AM
Michael,

I don’t have time ATM to examine this further, but on my XP system with a recent MinGW installation the 32-bit LongDouble.exe triggers an access violation exception in libstdc++-6!ZSt4cout. Here are the dependencies as returned by Dependency Walker:

KERNEL32.DLL
LIBGCC_S_DW2-1.DLL
LIBSTDC++-6.DLL
LONGDOUBLE.EXE
MSVCRT.DLL
NTDLL.DLL



I could test the 32 bit exe only with Windows XP Mode under Windows 7. Could you re-compile it from the source?

Gunther
Title: Re: Dealing with REAL10 values
Post by: qWord on April 07, 2013, 02:59:06 AM
the program requires libgcc_s_dw2-1.dll and libstdc++-6.dll, which can be found in gcc's bin folder.
You maybe use -static-libgcc for linking.

qWord
Title: Re: Dealing with REAL10 values
Post by: anta40 on April 07, 2013, 03:27:46 AM
Gunther's exe also crashes on my laptop, and indeed the cause is libgcc_s_dw2-1.dll not found in my gcc directory.
One possible explanation is Gunther and I are using different distros of mingw.

I'm using this, btw:
http://sourceforge.net/projects/mingwbuilds/files/host-windows/testing/4.8.0/32-bit/threads-win32/sjlj/x32-4.8.0-snapshot-20130315-rev196647-win32-sjlj.7z/download

So I recompile the code, and it works. And actually it's also compilable with MSVC 2012. Attached it for you guys (only dependent on kernel32.dll)  ;)

GCC 4.8 output:
Quote
Layout of data types:
=====================

Long Double (REAL 10)   = 12 Bytes
Double (REAL 8)         =  8 Bytes
Float (REAL 4)          =  4 Bytes

Results:
========

PI                      = 3.14159265358979323846264338327 ...
PI as Long Double Value = 3.1415926535897932385
PI as Double Value      = 3.141592653589793
PI as Float Value       = 3.141593

Press any key to continue ...

MSVC 2012 output:
Quote
Layout of data types:
=====================

Long Double (REAL 10)   = 8 Bytes
Double (REAL 8)         =  8 Bytes
Float (REAL 4)          =  4 Bytes

Results:
========

PI                      = 3.14159265358979323846264338327 ...
PI as Long Double Value = -8.8796093704934495e+043
PI as Double Value      = 3.141592653589793
PI as Float Value       = 3.144531

Press any key to continue ...
Title: Re: Dealing with REAL10 values
Post by: jj2007 on April 07, 2013, 03:50:40 AM
Double (REAL 8)         =  8 Bytes

Double looks real cool, but that's a problem of the forum software ;-)
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 05:53:36 AM
Hi anta40,

Gunther's exe also crashes on my laptop, and indeed the cause is libgcc_s_dw2-1.dll not found in my gcc directory.
One possible explanation is Gunther and I are using different distros of mingw.

I'm using this, btw:
http://sourceforge.net/projects/mingwbuilds/files/host-windows/testing/4.8.0/32-bit/threads-win32/sjlj/x32-4.8.0-snapshot-20130315-rev196647-win32-sjlj.7z/download

thank you for helping. Indeed, I did use gcc 4.6.2 and that behavior is a bit strange, because C++ isn't Visual Basic which needs sometimes this and that DLL. So, I'll upgrade the compiler.

Gunther
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 06:24:38 AM
Hi qWord,

the program requires libgcc_s_dw2-1.dll and libstdc++-6.dll, which can be found in gcc's bin folder.
You maybe use -static-libgcc for linking.

qWord

that was my next idea, too. But it doesn't help.

Gunther
Title: Re: Dealing with REAL10 values
Post by: Magnum on April 07, 2013, 08:26:48 AM
I am always finding C code, so I may as well assemble it.

I downloaded yasm.

Where would be a good place to get the header and lib files ?

I have some from my 2003 SDK, can I use them ?

Andy
Title: Re: Dealing with REAL10 values
Post by: MichaelW on April 07, 2013, 09:35:15 AM
I forgot to mention that both of the GCC-specific DLLs are in the MinGW bin directory.

After a recompile, with GNU C++ (GCC) version 4.7.2 (mingw32), the app runs OK and I get:
Code: [Select]
Layout of data types:
=====================

Long Double (REAL 10)   = 12 Bytes
Double (REAL 8)         =  8 Bytes
Float (REAL 4)          =  4 Bytes

Results:
========

PI                      = 3.14159265358979323846264338327 ...
PI as Long Double Value = 3.1415926535897932385
PI as Double Value      = 3.141592653589793
PI as Float Value       = 3.141593

:t

Also, I attempted qword’s suggestion:
Code: [Select]
:yasm -f win32 LongDouble.asm
g++ -v -c LongDouble.cpp
pause
g++ -v -static-libgcc -o LongDouble.exe LongDouble.o LongDouble.obj
pause

And while I can’t see anything in the -v output that looks like a warning or error, and the app still functions correctly, the dependencies do not change.
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 10:22:03 AM
Michael,

thank you for your help. :t

After studying the CERN sources again and again, I've found now the appropriate solution for simple C, too. The new added archive is LongC32.zip and should work fine. Here is the output:
Code: [Select]

Layout of data types:
=====================

Long Double (REAL10)    = 12 Bytes
Double (REAL8)          =  8 Bytes
Float (REAL4)           =  4 Bytes

Results:
========

PI                      = 3.14159265358979323846264338327 ...
PI as Long Double Value = 3.1415926535897932385
PI as Double Value      = 3.141592653589793
PI as Float Value       = 3.141593

Press any key to continue ...

Please check the batch file, because the command line for compiling the C source is a bit tricky. Unfortunately, it won't compile wit VC. But it should work too with Borland's and Intel's C compiler (but that's not tested). The appropriate 64 bit source is LongC64.zip inside that thread. (http://masm32.com/board/index.php?topic=1767.0)

Gunther
Title: Re: Dealing with REAL10 values
Post by: MichaelW on April 07, 2013, 10:55:05 AM
This time, the supplied EXE worked correctly.

A bit tricky?

I have in the past spent a significant amount of time trying to do this with a C app compiled with GCC, but who could have guessed that it would take an apparently undocumented:

 -D__USE_MINGW_ANSI_STDIO

switch?

Interesting, the dependencies this time are:

KERNEL32.DLL
LONGPI.EXE
MSVCRT.DLL
NTDLL.DLL

Title: Re: Dealing with REAL10 values
Post by: anta40 on April 07, 2013, 11:41:22 AM
Unfortunately, it won't compile wit VC.

It does  ;)

Code: [Select]
Layout of data types:
=====================

Long Double (REAL10)    = 8 Bytes
Double (REAL8)          =  8 Bytes
Float (REAL4)           =  4 Bytes

Results:
========

PI                      = 3.14159265358979323846264338327 ...
PI as Long Double Value = -88796093704934495000000000000000000000000000.0000000000000000000
PI as Double Value      = 3.141592653589793
PI as Float Value       = 3.144531

Press any key to continue ...

Title: Re: Dealing with REAL10 values
Post by: dedndave on April 07, 2013, 12:33:02 PM
that's a lot of digits for a "long double"   :P

ok - 17 signifigant digits - lol
nowhere near PI
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 07:58:19 PM
Michael and anta40,

It does  ;)

yes, it'll compile, but the output is garbage.

that's a lot of digits for a "long double"   :P

ok - 17 signifigant digits - lol
nowhere near PI

There are no long double (REAL10) values in the pure Windows world.

Gunther
Title: Re: Dealing with REAL10 values
Post by: dedndave on April 07, 2013, 08:10:50 PM
i don't know why not - it's the Real McCoy (http://en.wikipedia.org/wiki/The_real_McCoy)   :P
80-bit real is the "native" format for the FPU
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 08:18:47 PM
Dave,

i don't know why not - it's the Real McCoy (http://en.wikipedia.org/wiki/The_real_McCoy)   :P
80-bit real is the "native" format for the FPU

absolutely right and there are good reasons to do so. But times are changing, you know. The extended multi media register are now the new kids on the block. Brave new world.

Gunther
Title: Re: Dealing with REAL10 values
Post by: dedndave on April 07, 2013, 09:08:33 PM
i think SSE supports extended reals, no ?
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 09:47:58 PM
i think SSE supports extended reals, no ?

I think no. There's not enough room inside the registers.

Gunther
Title: Re: Dealing with REAL10 values
Post by: MichaelW on April 07, 2013, 10:14:12 PM
Looking at a very recent Intel manual, it looks like the choices are double-precision , single-precision, and half-precision (this only for conversion with single-precision, and with F16C extensions, whatever that is).

Title: Re: Dealing with REAL10 values
Post by: Gunther on April 07, 2013, 10:58:08 PM
Michael,

Looking at a very recent Intel manual, it looks like the choices are double-precision , single-precision, and half-precision (this only for conversion with single-precision, and with F16C extensions, whatever that is).

The so called half-precision is that. (http://half.sourceforge.net/) On the other hand, the Intel C++ compiler on Microsoft Windows supports extended precision, but requires the /Qlong‑double switch for long double to correspond to the hardware's extended precision format. That's a bit funny. One could find some information about that here. (http://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os/)

Gunther
Title: Re: Dealing with REAL10 values
Post by: dedndave on April 08, 2013, 12:44:44 AM
according to this paper,

http://www.cs.fsu.edu/~engelen/courses/HPC-adv/FP.pdf (http://www.cs.fsu.edu/~engelen/courses/HPC-adv/FP.pdf)

"double extended" is supported, but it does not appear to be quite the same as an FPU extended real
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 08, 2013, 12:56:56 AM
Dave,

"double extended" is supported, but it does not appear to be quite the same as an FPU extended real

of course, it's a system dependency. Thank you for the interesting paper. It's a good summary.

Gunther
Title: Re: Dealing with REAL10 values
Post by: anta40 on April 08, 2013, 01:37:26 PM
There are no long double (REAL10) values in the pure Windows world.

Do you have the Linux version of the code?
I'd like to give it a try.
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 09, 2013, 02:59:44 AM
Hi anta40,

Do you have the Linux version of the code?
I'd like to give it a try.

I'll re-compile the source and upload it - let me say - tomorrow. Do you need 32 or 64 bit Linux?

Gunther
Title: Re: Dealing with REAL10 values
Post by: anta40 on April 09, 2013, 12:59:34 PM
32-bit is fine. But if you don't mind, both 32-bit and 64-bit would be better.
 :biggrin:
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 09, 2013, 07:28:44 PM
Hi anta40,

32-bit is fine. But if you don't mind, both 32-bit and 64-bit would be better.
 :biggrin:

okay, I'll re-compile it for both targets. But under Linux isn't such a problem.

Gunther
Title: Re: Dealing with REAL10 values
Post by: Gunther on April 11, 2013, 12:20:40 AM
Hi anta40,

I've uploaded the Linux sources inside the 64 Bit Assembler sub-forum. You can find it here. (http://masm32.com/board/index.php?topic=1785.0) The archive contains the 64 bit sources as well the 32 bit sources. 32 bit Linux uses the same ABI like Windows 32 bit; so there are only minimal source changes necessary. But under 64 bit systems I had to change the assembly language source, because the underlying ABI is very different from Windows. I hope that helps.

Gunther