I might be doing something wrong.

I was trying to build a cross compiler (well I took a script that is to build a arm cross, and only did a search and replace... So there is plenty of room for error on by side.

Before I go and look deeper: Should it work. Or is the below correct and it is not yet possible?

C:/FPC/tag_build_2_6_0/fpcsrc/compiler/ppcx64.exe -Ur -Xs -O2 -n -Fui386 -Fusystems -FuC:/fpc/tag_build_2_6_0/fpcsrc/rtl/units/x86_64-win64 -Fii386 -FE. -FUi386
/units/x86_64-win64 -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at
this time
fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at
this time
fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems without support for an 80 bit extended floating point type to i386 is not yet supported at
this time
cutils.pas(154,1) Fatal: There were 3 errors compiling module, stopping Fatal: Compilation aborted

I wonder why Extended should not be supported in 64 bit mode. The FPU still exists, as it's required in 32 bit mode, and AFAIK it also is accessible in 64 bit code. Of course the FPU doesn't work together with the MMX/MMY registers, but for the few conversions required in a compiler this should not be a big problem?

DoDi

2012/8/28 Martin :

AFAIK, 80 bits floating point (extended) is not supported on win64 by Microsoft (it is on linux 64 bits).
For consequences see the user defined errors, which explain it. Remedy is writing/ / using softfloat emulation for calcutions in the compiler that require extended precision when targeting i386.

Vincent

-Fusystems -FuC:/fpc/tag_build_2_6_0/fpcsrc/rtl/units/x86_64-win64 -Fii386 -FE. -FUi386

> /units/x86_64-win64 -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas > fpcdefs.inc(160,2) Error: User defined: Cross-compiling from systems

without support for an 80 bit extended floating point type to i386 is not yet supported at

> this time I wonder why Extended should not be supported in 64 bit mode. The FPU

still exists, as it's required in 32 bit mode, and AFAIK it also is accessible in 64 bit code. Of course the FPU doesn't work together with the MMX/MMY registers, but for the few conversions required in a compiler this should not be a big problem?

The FPU is used on every x86_64 platform except Win64, because Microsoft says that we (as in developers) should not use the FPU on Win64, because it is considered deprecated there. Technically it is definitely possible, but "if in Rome, do as the Romans do"...

Regards,
Sven

Hi,

???? 29/8/2012 10:05 ??, ?/? Sven Barth ??????:

Am 29.08.2012 01:23 schrieb "Hans-Peter Diettrich" < >:

<snip>

Quoting from http://www.agner.org/optimize/calling_conventions.pdf :

"6.1 Can floating point registers be used in 64-bit Windows? There has been widespread confusion about whether 64-bit Windows allows the use of the
floating point registers ST(0)-ST(7) and the MM0 - MM7 registers that are aliased upon
these. One early technical document found at Microsoft's website says "x87/MMX registers
are unavailable to Native Windows64 applications" (Rich Brunner: Technical Details Of
Microsoft® Windows® For The AMD64 Platform, Dec. 2003). An AMD document says: "64-
bit Microsoft Windows does not strongly support MMX and 3Dnow! instruction sets in the
64-bit native mode" (Porting and Optimizing Multimedia Codecs for AMD64 architecture on
Microsoft® Windows®, July 21, 2004). A document in Microsoft's MSDN says: "A caller
must also handle the following issues when calling a callee: [...] Legacy Floating-Point
Support: The MMX and floating-point stack registers (MM0-MM7/ST0-ST7) are volatile. That
is, these legacy floating-point stack registers do not have their state preserved across
context switches" (MSDN: Kernel-Mode Driver Architecture: Windows DDK: Other Calling
Convention Process Issues. Preliminary, June 14, 2004; February 18, 2005). This
description is nonsense because it confuses saving registers across function calls and
saving registers across context switches. Some versions of the Microsoft assembler ml64
(e.g. v. 8.00.40310) gives the following message when attempts are made to use floating
point registers in 64 bit mode: "error A2222: x87 and MMX instructions disallowed; legacy
FP state not saved in Win64".
However, a public discussion forum quotes the following answers from Microsoft engineers
regarding this issue: "From: Program Manager in Visual C++ Group, Sent: Thursday, May
26, 2005 10:38 AM. It does preserve the state. It's the DDK page that has stale information,
which I've requested it to be changed. Let them know that the OS does preserve state of
x87 and MMX registers on context switches." and "From: Software Engineer in Windows
Kernel Group, Sent: Thursday, May 26, 2005 11:06 AM. For user threads the state of legacy
floating point is preserved at context switch. But it is not true for kernel threads. Kernel
14
mode drivers can not use legacy floating point instructions." (www.planetamd64.com/index.php?showtopic=3458&st=100). The issue has finally been resolved with the long overdue publication of a more detailed ABI
for x64 Windows in the form of a document entitled "x64 Software Conventions", well hidden
in the bin directory (not the help directory) of some compiler packages. This document says:
"The MMX and floating-point stack registers (MM0-MM7/ST0-ST7) are preserved across
context switches. There is no explicit calling convention for these registers. The use of
these registers is strictly prohibited in kernel mode code." The same text has later appeared
at the Microsoft website
(msdn2.microsoft.com/en-us/library/a32tsf7t(VS.80).aspx). My tests indicate that these registers are saved correctly during task switches and thread
switches in 64-bit mode, even in an early beta version of x64 Windows. The Microsoft C++ compiler version 14.0 never uses these registers in 64-bit mode, and
doesn't support long double precision. The Intel C++ compiler for x64 Windows supports
long double precision and __m64 in version 9.0 and later, while earlier versions do not.
The conclusion is that it is safe to use floating point registers and MMX registers in 64-bit
Windows, except in kernel mode drivers."

regards,

Dimitrios Chr. Ioannidis wrote

Quoting from http://www.agner.org/optimize/calling_conventions.pdf :

http://msdn.microsoft.com/en-us/library/ee418798(VS.85).aspx#Porting_to_64bit :

"The x87, MMX, and 3DNow! instruction sets are deprecated in 64-bit modes. The instructions sets are still present for backward compatibility for 32-bit mode; however, to avoid compatibility issues in the future, their use in current and future projects is discouraged."

Jonas

Jonas Hi,

Στις 31/8/2012 12:49 πμ, ο/η Jonas Maebe έγραψε:

in VS ver. 2005, 2010, 2012 has :

"The MMX and floating-point stack registers (MM0-MM7/ST0-ST7) are preserved across context switches. There is no explicit calling convention for these registers. The use of these registers is strictly prohibited in kernel mode code."

regards,

That is unrelated to whether or not their use is deprecated. If they weren't preserved across context switches, virtually no 32 bit Windows program would still work on 64 bit Windows.

Jonas

Thanks for the detailed information.

One thing seems to be clear: the instructions to save the CPU state have to be used in context switches. Now it depends on the available instructions, whether the FPU state is always included; this again may be different for the 32 and 64 bit instructions or drivers (dunno).

DoDi