From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: instructions for compiling cmu-cl
Date: 
Message-ID: <BtnApz.IH8.1@cs.cmu.edu>
    From: ·······@bimacs.BITNET (Yedidya Israel)
    
    Thanks to ···@NMSU.Edu that gave me the address ··········@cs.cmu.edu.

I've tried responding to your post, but had trouble getting mail to you.
Since the answer to your query is perhaps of general interest, I will post
it.

First, the internet address for technical queries and bug reports about CMU
CL is indeed ···········@cs.cmu.edu".  All project members and some of our
more intense users read this list, and the right person will answer
(assuming we can get mail to you).

On your original query, you wanted to know how to recompile CMU CL for a
new platform other than the Sparc.  Well, there are some bootstrapping
tricks involved in recompiling the system -- we can elaborate if necessary.
But the larger issue is that you can't just recompile this thing for some
other CPU.

Unlike AKCL, CMU CL is not just a vanilla, machine-independent C program.
There's a native-code compiler, so porting to a new platform requires
writing a new compiler back-end, plus some low-level routines, plus maybe
some serious tuning and re-design of the internal data formats to get full
efficiency from a new platform.  William Lott, our chief porting wizard,
has got this down to a few weeks for RISC machines running something close
to Mach/Unix, but it would take considerably longer for anyone else.

Porting to other operating systems is also a hassle, since we depend on
some of the memory management facilities in Mach.  SunOS and OSF/1 have
these same facilities, more or less; Ultrix, the old HP/UX, and other
bsd-based Unix systems do not.  We could port to bsd, with some months of
effort and a lot of code reorganization, but since all these systems are
allegedly being phased out in favor of OSF or some other more modern
version of Unix, we've decided to wait and let the world come to us.  In
the case of DEC, there have been a lot of delays in getting out their
OSF-like version of Ultrix.

We haven't done a lot of ports because there aren't a lot of widely-used
machines out there with Mach/OSF-style operating systems, and because for
some of the ports that we could easily do (SGI Indigo, IBM RS/6000),
we don't have the hardware available locally to support a porting effort.
Several of our external users have asked about a NeXT port, but porting to
the Motorola 68K would be more difficult than porting to yet-another-RISC,
and of little long-term value if NeXT switches to a RISC CPU in the near
future.  In any case, we don't have any of those machines to work on
either.

So for now the selection is Sparc under SunOS and Mach, Decstation (MIPS
CPU) under Mach/OSF, and the old, slow IBM RT under Mach (which we happen
to have a lot of).

-- Scott