Subject: Re: Cross-compiling CLISP?
Date: Monday 17th March 2008 06:28:36 UTC (over 10 years ago)
Hi Kaz, > I work as the Linux kernel and distro lead at a hardware company. I > developed a purely cross-compiled Linux distro from scratch; it would > be cool to include a CLISP package. The rules of the distro are that > everything builds on the ``tinderbox'' build machine. Under no > circumstances would we do something silly, like set up a hybrid build > environment consisting of x86 build machines and MIPS embedded boards. And the result of your distribution, built only on x86 machines, is then loaded into a ROM? And you don't have a "post-install" hook in your package system which is run on a machine of the target type? Then the only way to go, not only with clisp but with any Common Lisp implementation, is to load the entire bunch of .fas files on the target machine. I.e. don't use .mem files. Except for those implementations which can create cross-architecture memory images, such as SBCL. > How machine-specific are the .mem files? Can a .mem dumped on x86 be > read on big endian MIPS? Basically, a .mem file is a heap of pointers. Pointers are the preferred way of representation of references to objects, because they are directly supported by the CPU's instruction set. CLISP has a way to load .mem files while relocating all contents (if built with SPVW_PAGES). This would theoretically make it possible to reload 32-bit .mem files in 32-bit CPUs. With some knowledge of the internals of object layout in memory even swap the endianness. But migration from 32-bit to 64-bit in one step is too expensive; such code would be as complicated as the entire GC. I believe that this holds for most, if not all, Common Lisp implementations. The reason why a language such as Java or C# does not need .mem files is that many more things in these languages are declarative, whereas in CL they are dynamic. During the first startup, every symbol must be recorded in a dynamically built symbol table, and every function definition must be recorded in a symbol-value cell or symbol->function table. SBCL is different because man-years of work have been put into allowing cross-compilation of 1. fasl files, 2. memory images. > That is to say, the CLISP build could have two options that are > mutually exclusive: a) build a bootstrapping CLISP. This is like > normal CLISP except that SAVEINITMEM supports wiriting a memory image > readable on a particular target different from the build machine. b) > build a cross-compiled CLISP. It is not that simple. To build a cross-compiled .mem file, you need to be able to _cross-execute_ Lisp code. For example, if the code says (eval-when (load eval compile) (defconstant sys::*jmpbuf-size* #+x86 14 #+mips 18)) you need to be able to execute this code for producing a memory image, but in a way that does not clobber the building instance. Now try to do that... Bruno