GCC can also generate instructions that use the old x87 FPU, but when generating x86-64 code, the default is to use SSE2. On Mac OS X, the default is to use SSE2 even in 32-bit since all Intel Macs have SSE2. When it generates instruction for the 387, GCC does not set the precision of the FPU to the double format, so that computations are made in the 80-bit double-extended format, and then rounded to double when assigned.
As a consequence:
If you use only double computations, Visual Studio should generate a program that computes exactly at the precision of the type, because it is always double(**). And if on the GCC side you use -msse2 -mfpmath=sse, you can expect GCC to also generate code that computes at the precision of doubles, this time by using SSE2 instructions. The computations should match.
Or if you make both GCC and Visual Studio emit SSE2 instructions, again, the computations should match. I am not familiar with Visual Studio but the switch may be /arch:SSE2.
This does not solve the problem with math libraries, which is indeed an unsolved problem. If your computations involve trigonometric or other functions, you must use the same library as part of your project on both sides. I would recommend CRlibm. Less accurate libraries are fine too as long as it's the same library, and it respects the above constraints (using only double or compiled with SSE2 on both sides).
(*) There may be a way to instruct it to generate SSE2 instructions. If you find it, use it: it will solve your particular problem.
(**) modulo exceptions for infinities and subnormals.
DEFLNG A-Z
J = 4381911
A = 52
B = 4 * (J + A + 1401) + 3
G = 5 * INT((B MOD 1461) / 4) + 2
D = INT((G MOD 153) / 5) + 1
M = ((INT(G / 153) + 2) MOD 12) + 1
PRINT D; M
Can you correct the code - displays the error in the first line.
To FellippeHeitor
I see you have a lot to say in this Forum. Therefore, I agree to delete my profile from qb64.org/forum.
Goodbye
Therefore, I agree to delete my profile from qb64.org/forum.
Goodbye
Sorry to see Ryster go. I'm world's worst programmer in that I have very little understanding sometimes as to why somethings work and why some don't work. The issue Ryster raised I have come across before - clueless as to why it worked in Qbasic and not QB64x64, so just threw different things at it until I found the Round function solved my problem. I was hoping this thread would give some more insight and walla the "specific system architecture" was raised.
So is that referring to the OS of Windows, Apple, Android etc, or Hardware installed in a computer, or is that referring to how QB64 deals with 32 bit values or 64 bit values applying the same operation (ie 10 x 354 is handled differently if using QB64x32 v's using QB64x64).
Differences between x87 FPU and SSE2
FPU (x87) instructions provide higher precision by calculating intermediate results with 80 bits of precision, by default, to minimise roundoff error in numerically unstable algorithms (see IEEE 754 design rationale and references therein). However, the x87 FPU is a scalar unit only whereas SSE2 can process a small vector of operands in parallel.
If codes designed for x87 are ported to the lower precision double precision SSE2 floating point, certain combinations of math operations or input datasets can result in measurable numerical deviation, which can be an issue in reproducible scientific computations, e.g. if the calculation results must be compared against results generated from a different machine architecture. A related issue is that, historically, language standards and compilers had been inconsistent in their handling of the x87 80-bit registers implementing double extended precision variables, compared with the double and single precision formats implemented in SSE2: the rounding of extended precision intermediate values to double precision variables was not fully defined and was dependent on implementation details such as when registers were spilled to memory.
@Fellippe, it is a very odd expression indeed and very rarely used, but I thought that I'd foist it upon everyone.