To: "John R. Dunning" <jrd@harlequin.com>
cc: seamew-l@dircon.co.uk
Subject: Re: More python backend questions 
Fcc: out-copy
In-reply-to: Your message of Thu, 10 Nov 1994 14:56:49 -0500.
             <1737.199411101956@squash.harlequin.com> 
Reply-To: ram+@cs.cmu.edu
--------
[seamew-l cc because this concerns all cross compilation.]

    From: "John R. Dunning" <jrd@harlequin.com>
    Date: Thu, 10 Nov 1994 14:56:49 -0500
    To: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
    Subject: More python backend questions
    
    So I've got this m68k backend that's almost on the verge of being able
    to generate code.  Interesting issue that came up while debugging the
    thing: How do you guys manage multiple backends when you're
    cross-compiling for another platform?  Do you simply load the new
    backend in, with all its attendant definitions, and essentially break
    the compiler for compiling to the native platform?
    
    I saw all the stuff for unusing these packages and using those
    packages over there, but it seemed to me that really only helps you at
    definition time, ie it prevents you from smashing the wrong values
    into constants etc.  What about the code that uses them?  Is there not
    an issue of bunch-of-files-in-the-compiler being compiled with one
    backend's constants, and needing to be recompiled with another's?

Actually, we do support cross-compilation without breaking the running
compiler, but the mechanism isn't completely formalized.  Generally, we've
hand-built two files for each architecture we wanted to cross-compile to:

<arch>-setup.lisp
    This file is loaded before compiling the cross-backend.  It says where
    to find the new backend, and calls c::new-backend to create a new
    backend to hold the definitions.

<arch>-boot.lisp
    Once the new backend has been compiled, this file is used to load the
    backend in order to actually do cross compilation.  The compile-all
    script has a -bootstrap option which can be used to load this file.

I've appended a version of x86-setup and x86-boot.  Note however, that
these files often tend to need more-or-less custom hacks.  The compiler
backend itself should be purely parameterized by the c:backend structure,
but there are other things that can differ across platforms.  One major
category is os-specific object definitions such as sigcontext.  These
definitions can generally be put in the <arch>-boot file, since any
definitions in the running system have been inlined when the system was
compiled.

Also, here some notes from William somewhat explaining the contents of
these files:
________________________________________________________________
Cross-compilation notes.

To build a cross compiler:

(load "tools:setup")
(comf "tools:setup" :load t)
(c::new-backend "<name>" '(<features-to-add>) '(<features-to-remove>))
(setf (search-list "target:") '(<object-dir> <source-dir>))
(load "tools:comxcom")

To load a cross compiler:

(gc-off)
(lisp::clear-auto-gc-trigger)
(setf (search-list "target:") '("sparcalpha:" "clisp:src/alpha/")
      (search-list "c:") '("target:compiler/")
      (search-list "vm:") '("c:sparc/" "c:generic/")
      (search-list "assem:") '("target:assembly/" "target:assembly/sparc/"))
(load "target:tools/setup")
(c::new-backend "<name>" '(<features-to-add>) '(<features-to-remove>))
(load "c:loadbackend")

;; Not, of course, if this is part of a bootstrap file.
(setf (search-list "target:") '("sunosalpha:"))
(setf c:*backend* c:*target-backend*)
(lisp::purify)
(gc-on)

- The name->type-class mapping for aliens is in a single hash table.  Needs
to be moved into the info environemnt or made part of the backend.  Then
new alien-type-methods need to be loaded with the backend.

- The make-array deftransform in arraytran is VM specific, and should be
somewhere else.
________________________________________________________________

x86-setup.lisp
________________________________________________________________

(in-package "USER")

(dsl "target:" "mycom:" "clisp:src/alpha/")

(load "target:tools/setup" :if-source-newer :load-source)
(comf "target:tools/setup" :load t)

(setf *interactive* nil)
(setf *gc-verbose* nil)
;(setf *compile-print* nil *compile-verbose* nil)

(c::new-backend "X86" '(:x86 :mach :new-assembler) '(:sparc :mips :sunos))
(use-package :new-assem :x86)
________________________________________________________________

x86-boot.lisp
________________________________________________________________

(in-package "USER")

(gc-off)
(lisp::clear-auto-gc-trigger)

(setf (search-list "mycom:")
      '("/afs/cs/project/clisp/hackers/wlott/"
	"/afs/cs/project/clisp/src/alpha/"))
(setf (search-list "c:") '("mycom:compiler/"))
(setf (search-list "vm:") '("c:x86/" "c:generic/"))
(setf (search-list "assem:") '("mycom:assembly/x86/"))

(c::new-backend "X86" '(:x86 :mach :new-assembler) '(:sparc :mips :sunos))
(eval '(use-package :new-assem :x86))

(load "c:loadbackend")
(load "vm:new-genesis")

(setf lisp::*genesis-core-name* "mycom:lisp/kernel.core")
(setf lisp::*genesis-c-header-name* "mycom:lisp/internals.h")
(setf lisp::*genesis-map-name* "mycom:lisp/lisp.map")
(setf lisp::*genesis-symbol-table* "mycom:lisp/lisp.nm")

(setf c:*backend* c:*target-backend*)

(lisp::purify)
(gc-on)
________________________________________________________________