[plt-dev] First patch for MzScheme on Win64/x86_64
Here is the patch that allows MzScheme to compile and run on
Win64/x86_64 architecture, with Visual Studio 2005.
I made 'diff -Naur between the 'plt-4.2.3 folder from the source zip and
my modified one (which I have cleaned up just before). the result is
called win64.patch, and is attached to this email.
Here is an overview of the changes:
-> mzscheme/sconfig.h
+ Added a _WIN64 check to adjust SCHEME_PLATFORM_LIBRARY_SUBPATH,
deactivate USE_MZ_SETJMP, and deactivate the JIT
-> mzscheme/mzjs86.c
+ Added a _WIN64 check to not generate scheme_mz_setjmp &
scheme_mz_longjmp functions (since inline assembly is not possible with
MSVC 64bits). maybe it could be better to use directly the USE_MZ_SETJMP
define to enable/disable these functions
-> Solution & project files : mzscheme.sln, mzscheme.vcproj,
libmzgc.vcproj, libmzsch.vcproj
+ Added the new platform 'x64' to solution & project files (with
parameters copied from the Win32 platform)
+ In all configurations of this new platform (debug/release), added the
/Wp64 switch (under Properties>C/C++>General)
+ In all configurations of this new platform (debug/release) removed the
/MACHINE:I386 from command line of the Linker (under Linker\Command Line)
+ In libmzsch.vcproj, somes files from the new libffi have been added
(win64.S and ffi64.c), which are included with the x64 platform and
excluded from Win32 platform. The file win64.S is an assembly file which
have a specific build rule (see later). The file win32.c have been
excluded from the x64 platform (but still included with the win32 platform).
-> foreign\libffi_msvc\*
+ There is a lot of changes here, since I have replaced most of the
files with the ones from the latest libffi version (3.0.9):
- replaced: ffi.c, ffi.h, ffi_common.h, ffitarget.h, prep_cif.c,
LICENSE, README, types.c, win32.S
- added: win64.S, ffi64.c
- skipped: fficonfig.h (since the configure script of libffi is not
really MSVC aware, I kept the one from PLT since it was already ported
for MSVC, and added a few lines from the newer one about the FFI_HIDDEN
stuff).
- no changes: win32.c
+ I made a small modification on the new ffi.h: a swith between
X86_WIN32 and X86_WIN64 depending the the target platform (simply a
_WIN64 check)
As you may have noticed, the file win64.S have been added to the
solution, with a new build rule in the project. It is an assembly file
specific for the win64 ABI and implements the convention ffi_call_win64.
Since MSVC compiler does not handle inline assembly in C code, it is
mandatory to use the Microsoft Assembler (ml64.exe) to generate this
one. Hopefully the file have both gas syntax and ml64 syntax (switched
by a #ifdef on _MSC_VER), plus a few #defines.
Since ML64 does not support neither preprocessor directives nor C style
comments in assembly files, I kept only the assembly code with ml64
syntax. For the #defines, I commented them in the file (using ml64
syntax) and I passed them as /D parameters to the assembler command line
(see the build rule for this file in the project). Well, this is a
little bit dirty, but it works. Maybe there is room for improvement: try
to take the original win64.S from libffi and see what you can do with.
-> foreign\foreign.c
+ Small modification to call the new FFI_WIN64 abi when necessary
-> mzscheme\scheme.h
+ Modified the OBJ_TO_LONG macro to support the "long long" syntax under
_WIN64. Otherwise with the /Wp64 swith, the compiler was getting crazy
on warnings (conversion from Scheme_Object* to long) since this macro is
used everywhere..
A few remarks about what's remaining to be done:
!! Important !! I have found that now libffi have been updated to the
latest version, the win32 build of MzScheme does still compile, but does
not link anymore! It is because the new libffi have added a few assembly
functions into Win32.S. Since the assembly code present in this file
have been inlined manualy in C functions of win32.c for PLT, the new
functions must be inlined too (we can't use the Microsoft Assembler for
this one because there is only gas syntax). Anyway, this should not be
too complicated to do.
+ Now the remaining problems are the conversion warnings:
- conversion from 'size_t' to long or int(mostly calls to strlen ())
- conversion from '__int64' to long or int (pointer arithmetic, for
string manip and regex, stack manipulation, SCHEME_INT_VAL)
- etc..., etc...
Just to give a try, I have used 'mzlonglong as a replacement for 'long
when there is a warning. This typedef seems to work as a
"cross-platform-architecture long" but hell! this kind of modification
is propagating like a virus all over the code. Since I'm not sure about
this, I have canceled these changes.
+ a small modification must be done in mzscheme\dynsrc, since the .bat
files are using the -machine:X86 for the 'lib command.
+ Make the JIT work on LP64 architecture.
+ The tests result (quiet.ss) are quite good... until a crash happens in
Section(modprot) in read.c. Some kind of unmarshaling problem with .zo
data. I wasn't able to figure out why for now, but I suspect a
conversion problem somewhere...
Anyway, I think the win64 port is on its way.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: win64.patch
URL: <http://lists.racket-lang.org/dev/archive/attachments/20100113/9a11bed4/attachment.ksh>