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/archive/dev/attachments/20100113/9a11bed4/attachment.ksh>
