[no subject]

[Rob_MacLachlan@LISP-PMAX2.SLISP.CS.CMU.EDU]

    Date: Thu, 12 Dec 91 00:19:20 -0500
    From: Richard Stallman <rms@gnu.ai.mit.edu>
    Message-Id: <9112120519.AA01380@mole.gnu.ai.mit.edu>
    To: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
    Cc: friedman@gnu.ai.mit.edu
    
    What parts of the system cannot be cross compiled,
    and how can one get them ported to a new system?

I should have been clearer.  The compiler and stuff it needs can be cross
compiled.  Some other subsystems (the CLX X11 interface and the PCL object
system) can't be cross compiled, but they can be native compiled by a
system that doesn't contain them.
    
    Given sources, is it possible to produce a binary for a new
    machine straightforwardly, or does it require difficult bootstrapping?

If by a "new machine" you mean a new architecture, then it isn't
straightforward, even ignoring any bootstrapping issues.  We figure it
takes 2-4 wizard-months to retarget the compiler.  I have also not finished
the compiler retargeting documentation.
    
    This would be good.  But what we really need is to avoid anything
    in the distribution that is compiled specifically for one machine.
    
    Here is an idea.  Suppose you provide a bytecode interpreter and
    provide the files needed for real compilation in bytecode form.  This
    would be enough to get the system started, compile the Lisp code for
    your own machine, and get going.  And it would be machine-independent.
    
    What do you think?

Something along those lines would definitely be possible, but it would also
be a project of the same magnitude as a port to a new hardware
architecture.  Though this would only have to be done once, it is hard for
us to justify spending that much time if the only benefit is to make it
possible to bootstrap the system without a cross-compilation environment.

I'm seriously considering the idea of some sort of byte-code interpreter,
but this was more to provide a compact code representation than for
portability.  I'll keep the bootstrapping issue in mind when doing the
design.

Another possiblity would be to support some sort of compile-to-C strategy,
or to directly hook into the gcc backend.

  Rob