Why MaxDouble does not equal to MaxDouble?

[tetrastes]

We are in a situation were progress is REGRESSION !

Sic!

[marcov]

Sorry, this article does not push out anything related to the x87. It specifies how and in which order parameters are passed to sytem calls, how they are aligned. It tells about how the 87 FPU registers must be handled.

I only see that st0..st7 is saved across calls. Do I miss something where x87 is specified? All float examples seems to use SSE2 XMM. It is a long article, so maybe I misread, but could you quote the relevant bits ?

[BrunoK]

I only see that st0..st7 is saved across calls. Do I miss something where x87 is specified? All float examples seems to use SSE2 XMM. It is a long article, so maybe I misread, but could you quote the relevant bits ?

All float examples seems to use SSE2 XMM. Because Windows does not use the 87 FPU.

The alignment, if it was required for a call to Windows as i expose derives from :

func4(__m64 a, __m128 b, struct c, float d, __m128 e, __m128 f);
// a in RCX, ptr to b in RDX, ptr to c in R8, d in XMM3,
// ptr to f pushed on stack, then ptr to e pushed on stack

_m128 is passed by reference.

Somewhere else in MS doc it is stated that things are aligned on 64 bit. Some should be aligned on 128 bit, but here the fun is that cmem loses the 16 byte align due to the memsize being stored at the beginning of the allocated block ... That causes absolutely no trouble.

Anyway the Windows ABI has nothing to say about how the compiler should lay out its generated code. x87 FPU instructions are inlined by the compiler in the generated code (as is probably done in linux x86_64 or i386 floats).

[BrunoK]

Windows x86_64 ABI deprecated the x87 CPU, and specifies to use SSE2 for floating point.

Link ?

[marcov]

Windows x86_64 ABI deprecated the x87 CPU, and specifies to use SSE2 for floating point.

Link ?

They were Windows XP era documents in the period before Vista came out, MSDN has been redone several times over.  However wikipedia still hints on it

The following additional characteristics apply to all x64 versions of Windows:
...
Early reports claimed that the operating system scheduler would not save and restore the x87 FPU machine state across thread context switches. Observed behavior shows that this is not the case: the x87 state is saved and restored, except for kernel mode-only threads (a limitation that exists in the 32-bit version as well). The most recent documentation available from Microsoft states that the x87/MMX/3DNow! instructions may be used in long mode, but that they are deprecated and may cause compatibility problems in the future.[110] (3DNow! is no longer available on AMD processors, with the exception of the PREFETCH and PREFETCHW instructions,[112] which are also supported on Intel processors as of Broadwell.)

IIRC this was never revoked for Windows XP64. Note also that the remark that it wasn't true was tested experimentally. It took quite a while before it was documented.

[BrunoK]

They were Windows XP era documents in the period before Vista came out, MSDN has been redone several times over.  However wikipedia still hints on it

Wikipedia, hum ... very up to date.

The following additional characteristics apply to all x64 versions of Windows:
...
Early reports ... etc ..

Its a bit like when they do modelling with climate or did covid modelling but couldn't reproduce results on different machines. I always suspected that calculation accuracy was involved. If you read and follow the link (wiki mind you ...)  that I mentioned above, you may grasp a bit of what I understand about that 54/63 bit mantissa and a small introduction why the 87 FPU settled for 80 bit extended, money, technological capacity and ACCURACY.
There is no reason to castrate our programs in the name of "Windows support only 64 bit floats".

IIRC this was never revoked for Windows XP64. Note also that the remark that it wasn't true was tested experimentally. It took quite a while before it was documented.

Word salad, what was revoked and what and where was it stated, documented ?

[marcov]

IIRC this was never revoked for Windows XP64. Note also that the remark that it wasn't true was tested experimentally. It took quite a while before it was documented.

Word salad, what was revoked and what and where was it stated, documented ?

I don't understand. You want the date it was not revoked ? 

[BrunoK]

I don't understand. You want the date it was not revoked ? 

A quote from some valid source that states what you describe ?

Do not try to drown the fish, please.

[BrunoK]

Maybe some one could correct Wikipedia entry re Extended entry that states

Turbo Pascal (and Object Pascal or Delphi) has an extended 80 bit type available in addition to real / single (32 bits) and double (64 bits), either natively (when a 80x87 coprocessor is present) or emulated (through the Turbo87 library); this extended type is available on 16, 32, and 64 bit platforms, possibly with padding.[32]

And clarify the the windows 64 bit version doesn't support 80 bit floats with processors equiped with 87 FPU.

[BrunoK]

Maybe some one could correct Wikipedia entry re Extended entry that states

Turbo Pascal (and Object Pascal or Delphi) has an extended 80 bit type available in addition to real / single (32 bits) and double (64 bits), either natively (when a 80x87 coprocessor is present) or emulated (through the Turbo87 library); this extended type is available on 16, 32, and 64 bit platforms, possibly with padding.[32]

And clarify the the windows 64 bit version doesn't support 80 bit floats with processors equiped with 87 FPU.

Correct : And clarify the Windows 64 bit version of the Free Pascal Compiler doesn't support 80 bit floats with processors equiped with 87 FPU.

[Thaddy]

As I wrote before: you can support the fpu on win64 but it takes a recompile and Florian gave the instructions for it.
If it is sane to do so is a second question.
You can detect some support for higher precision, because on 64 bit AMD/Intel vectorcall is already supported and there are some type definitions for 128 - a packed record with two 64 bit values - HVA. I think 256 bit and 512 bit are still missing as is much of the compiler infrastructure to work with them, although the inline assembler code is already supported, so the appropiate registers - ABI conformant - will work for xmm and possibly ymm. So it is not as gloomy as you write.

[BrunoK]

As I wrote before: you can support the fpu on win64 but it takes a recompile and Florian gave the instructions for it.

Where are these instrructions, I've asked you repetidively and many times but you never supplied the information.

Repeat : You never supplied the information

If it is sane to do so is a second question.
You can detect some support for higher precision, because on 64 bit AMD/Intel vectorcall is already supported and there are some type definitions for 128 - a packed record with two 64 bit values - HVA. I think 256 bit and 512 bit are still missing as is much of the compiler infrastructure to work with them, although the inline assembler code is already supported, so the appropiate registers - ABI conformant - will work for xmm and possibly ymm. So it is not as gloomy as you write.

Word salad.

[BrunoK]

https://gitlab.com/freepascal.org/fpc/source/-/issues/40928
It's not me ...

[Thaddy]

If you can not find it on the forum, it is probably on the mailing list.
I could not find it quickly  myself too, but I know it is there.

[BrunoK]

If you can not find it on the forum, it is probably on the mailing list.
I could not find it quickly  myself too, but I know it is there.

Much Talk. No show. ;-)