Re: Cross-compiling CLISP?

[Bruno H. <ha...@il...>]

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