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
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
Michael,
Quote from: 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
I could test the 32 bit exe only with Windows XP Mode under Windows 7. Could you re-compile it from the source?
Gunther
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
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 ...
Quote from: anta40 on April 07, 2013, 03:27:46 AM
Double (REAL 8) = 8 Bytes
Double looks real cool, but that's a problem of the forum software ;-)
Hi anta40,
Quote from: 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
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
Hi qWord,
Quote from: 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
that was my next idea, too. But it doesn't help.
Gunther
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
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:
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:
: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.
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:
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
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
Quote from: Gunther on April 07, 2013, 10:22:03 AM
Unfortunately, it won't compile wit VC.
It does ;)
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 ...
that's a lot of digits for a "long double" :P
ok - 17 signifigant digits - lol
nowhere near PI
Michael and anta40,
Quote from: anta40 on April 07, 2013, 11:41:22 AM
It does ;)
yes, it'll compile, but the output is garbage.
Quote from: 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
There are no long double (REAL10) values in the pure Windows world.
Gunther
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
Dave,
Quote from: 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
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
i think SSE supports extended reals, no ?
Quote from: dedndave on April 07, 2013, 09:08:33 PM
i think SSE supports extended reals, no ?
I think no. There's not enough room inside the registers.
Gunther
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).
Michael,
Quote from: 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).
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
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
Dave,
Quote from: dedndave on April 08, 2013, 12:44:44 AM
"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
Quote from: Gunther on April 07, 2013, 07:58:19 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.
Hi anta40,
Quote from: anta40 on April 08, 2013, 01:37:26 PM
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
32-bit is fine. But if you don't mind, both 32-bit and 64-bit would be better.
:biggrin:
Hi anta40,
Quote from: 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:
okay, I'll re-compile it for both targets. But under Linux isn't such a problem.
Gunther
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