Hi Anton,

 This is great! I am going to test x64 SBCL for Windows with large CL applications (they consume up to 8G of memory and they use threads), and I will collect the issues list (if any) in a month or so.
 It will be nice to see this stuff merged into the main repository, at least with "experimental" status. People who are going to use it (like me) will probably help to fix the bugs. Anyway, this is a cool thing, and I hope that intergation issues will be eventually solved, especially when people find it to be stable and useful for their goals. 

Thank you,

2011/3/11 Anton Kovalenko <anton@sw4me.com>

Dear SBCL developers and users:

I think the time has come to describe some further progress in my
(threaded-SBCL-for-Windows) code repository.

[ http://www.siftsoft.com/inprogress/forknews.html ]
[ http://github.com/akovalenko/sbcl-win32-threads ].

Major part of my effort during the last week or two had gone into 64-bit
MS Windows port of SBCL for AMD64 architecture. I'm glad to announce
that Windows AMD64 support is now fully functional. X86-64 binaries
(MSI installer and an additional standalone executable) are available at
[ http://www.siftsoft.com/inprogress/forknews.html ].

64-bit and 32-bit version are now built from the same source tree. Since
this day, I'm going to provide updates for both platforms

The binaries mentioned above have as
(lisp-implementation-version). The old weird version numbering is now
gone; first four items in new version number correspond to last merged
upstream SBCL (sub-)version.

SBCL for Windows/AMD64 supports threading, interrupts, and alien
callbacks, invoked from foreign threads and from Lisp threads
alike. Like SBCL/Win32/X86, this port also works on Wine (MS Windows API
`Not an Emulator' for Linux), when Wine is compiled to support 64-bit
binaries (`combined' installation of 32-bit and 64-bin Wine to a single
prefix also works).

There are some (relatively minor) issues with that platform:

 * interrupted thread backtraces are inconveniently truncated;

 * unwinding with SEH frames is not supported on this platform yet (it
  becomes a problem when a foreign C call is invoked from a Lisp
  callback, and then it exits non-locally into a foreign C frame below
  [Lisp unwind cleanups between C frames won't run], or when a Lisp
  routine invoked from a C[++] one unwinds across the foreign frame [C
  SEH handler for stack unwinding won't run].

 * About 10-20 compiler warnings on type mismatches are still there;
  some of them point at really harmful code paths -- but those cases
  affect LDB and monitor, not influencing SBCL behaviour during normal

Non-Windows SBCL may now be built from the same tree (well, at least I'm
sure that it builds for linux-X86[-64]; didn't test another CPU
families, but chances that those configurations are affected should be
significantly lower than for X86* builds).

As of my plans related to inter-thread signalling simplification (GC and
interrupts) on platforms with safepoints: related code was rewritten
(almost from scratch) and is more intelligible now; in its current
state, this code is still unobvious to a casual readed -- but, at least,
with enough time in hands, i _can_ explain how it works (and why).

Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia

Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
Sbcl-devel mailing list