[ Home ]
SBCL Internals

The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed
[ Home ] [ Recent Changes ] [ About CLiki ] [ Text Formatting ]

A port of CMUCL's HPPA backend to SBCL was started on Friday 9th August. The initial target will be Linux, mostly because (a) Christophe Rhodes has access to one and (b) the Debian project can autobuild binaries.

Current Status: Through cold-init?; past first triggered GC, into PCL. My machine at this point stops responding, probably because it's weak and feeble. ldso-stubs.S magic needs looking at, as currently there are linking errors.

New with this porting effort: an elisp file to do most of the renaming for you. Doesn't catch everything, but it's a start. Also, be sure to define a VOP for COMPLEX-VECTOR-P?, as this is new to SBCL.

An observation, which may or may not be a bug: the cmucl backends often have:
(eval-when (compile eval) (defmacro def-something ...))
(def-something ...)

This doesn't work in sbcl's cross-compilation regime (explanation wanted); convert it instead to
(macrolet ((def-something ...)) (def-something ...)

(This is "working as designed." There's an ambiguity about what DEFMACRO within EVAL-WHEN (COMPILE EVAL) means when truly cross-compiling. Should it define a host macro, a target macro, or both? CMU CL doesn't distinguish very carefully between xc host and target macros, so it doesn't care about the ambiguity. SBCL does care, and code which was written without regard for the ambiguity tends not to do what is expected. Perhaps SBCL could've been written with different default behavior, perhaps requiring less conversion of average CMU CL code? I'm not sure: I just made it do something I could understand, without thinking much about do-what-CMU-CL-code-tends-to-mean. But I am fairly sure that such different default behavior wouldn't be more fundamentally right than what it does. -- WHN)

SBCL porting has detected a Linux kernel bug; kernel versions up to 2.4.19-pa3 did not handle the overflow trap needed for add and subtract to fix up bignums. After discussion with Carlos O'Donell, a patch to correct this has been submitted; a workaround has also been put in place in the SBCL codebase.


This page is linked from: CPU   index   PA  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively