From: Anton K. <an...@sw...> - 2011-03-11 07:12:06
|
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 simultaneously. The binaries mentioned above have 1.0.46.32.263.kovalenko.wth 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 work. 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 |