Disable the INT64_AS_LONG_LONG
I'm surprised that you needed this, since VS2005 does support the "long
long" syntax.
If you pass the Microsoft win64 compiler the /Wp64 switch, it does a
good job of detecting places where a pointer value is being converted to
an int or long instead of an intptr_t or uintptr_t. Clean up that and
you should be most of the way there.
Ben
On 1/11/2010 9:39 AM, Matthew Flatt wrote:
I'm impressed that you got it working, and I'd appreciate patches for
what you have so far.
To test, run
plt/collects/tests/mzscheme/quiet.ss
Yes, the JIT problem is surely LP64 vs. LLP64; the JIT generates 64-bit
operations for data structures that contain `long's. I think we'll
eventually have to change most `long's in the MzScheme code to some new
type that maps to `__int64' under Windows and `long' elsewhere.
The plan for MrEd is still to get rid of the current C++ code and
replace it with a new set of bindings that are implemented through the
FFI. The new bindings are implemented in a way that avoids the setjmp
problem. I hope to have that mostly working by March or so, but it's
difficult to predict.
At Mon, 11 Jan 2010 17:27:14 +0100, Gabriel Cuvillier wrote:
Hi everyone!
I managed to port MzScheme (CGC variant) to x86_64 on Win64 using Visual
Studio 2005.
I have done this port because I want to embed a Scheme implementation
into a large C++ 32/64 bits app on windows, and MzScheme seems to be the
ONLY implementation which is both MSVC-compilable and SWIG-available!
(No, I don't want to use Python :)
It is in "alpha" version, but it compiles and runs successfully on my
machine. The major restriction is that there is no JIT.. I wasn't able
to figure out why the JIT is crashing, but I suspect compatibility
problems with the LLP64 architecture of MSVC compilers (instead of LP64
used with GCC compilers).
The main modifications are:
-> sconfig.h: new target for WIN64 (MSC& _WIN64). Same as WIN32 but:
Disable the JIT
Disable the INT64_AS_LONG_LONG
Disable USE_MZ_SETJMP (and remove contents in the mzsj86.c).
Apparently
it could cause problems with MrEd in the future, but seems to be ok for
MzScheme.
-> Update libffi to the latest version. The main problem is with the
libffi version used which is not supporting win64. The latest one does,
and it seems to work for other projects (I think the JRuby team use it).
After a few headaches with the Microsoft Assembler, as well as obscure
defines, I finally managed to make it work.
-> Plus a minor hacks around...
With these actions, MzScheme compiles and runs. I still need to make a
lot more tests (is there any unit tests available?). There is more work
remaining to be done:
-> Lots of warning because of conversion between "size_t" to "long"
(LLP64 vs LP64). Should not cause too much problems for now since sizes
are not easily above 2GB...
-> Some warning because of conversion between "__int64" to "long" (LLP64
vs LP64 as always). They are more dangerous I think.
-> Make the JIT working.
After that, it should be possible to continue the port with MrEd (and
wxWidgets)...
If someone have some hints about the JIT stuff, or general infos about
the best way to handle LLP64 vs LP64 (should I pass everything from
"long" to "long long"?), help is welcome...
PS: apologies for my english spelling.
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
