[fpc-devel] cross copiling x86_64 to i386 ?
Dimitrios Chr. Ioannidis
d.ioannidis at artesoft.gr
Thu Aug 30 23:29:32 CEST 2012
???? 29/8/2012 10:05 ??, ?/? Sven Barth ??????:
> Am 29.08.2012 01:23 schrieb "Hans-Peter Diettrich"
> <DrDiettrich1 at aol.com <mailto:DrDiettrich1 at aol.com>>:
> > 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"...
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
are unavailable to Native Windows64 applications" (Rich Brunner:
Technical Details Of
Microsoft® Windows® For The AMD64 Platform, Dec. 2003). An AMD document
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
Microsoft® Windows®, July 21, 2004). A document in Microsoft's MSDN
says: "A caller
must also handle the following issues when calling a callee: [...]
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
context switches" (MSDN: Kernel-Mode Driver Architecture: Windows DDK:
Convention Process Issues. Preliminary, June 14, 2004; February 18,
description is nonsense because it confuses saving registers across
function calls and
saving registers across context switches. Some versions of the Microsoft
(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
FP state not saved in Win64".
However, a public discussion forum quotes the following answers from
regarding this issue: "From: Program Manager in Visual C++ Group, Sent:
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
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
mode drivers can not use legacy floating point instructions."
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
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
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
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."
Dimitrios Chr. Ioannidis
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel