home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / lisp / 2311 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  3.1 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!fs7.ece.cmu.edu!crabapple.srv.cs.cmu.edu!news
  2. From: sef@sef-pmax.slisp.cs.cmu.edu
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: instructions for compiling cmu-cl
  5. Message-ID: <BtnApz.IH8.1@cs.cmu.edu>
  6. Date: 27 Aug 92 13:56:18 GMT
  7. Sender: news@cs.cmu.edu (Usenet News System)
  8. Organization: School of Computer Science, Carnegie Mellon
  9. Lines: 53
  10. Nntp-Posting-Host: sef-pmax.slisp.cs.cmu.edu
  11.  
  12.  
  13.     From: yedidya@bimacs.BITNET (Yedidya Israel)
  14.     
  15.     Thanks to ted@NMSU.Edu that gave me the address cmucl-bugs@cs.cmu.edu.
  16.  
  17. I've tried responding to your post, but had trouble getting mail to you.
  18. Since the answer to your query is perhaps of general interest, I will post
  19. it.
  20.  
  21. First, the internet address for technical queries and bug reports about CMU
  22. CL is indeed "cmucl-bugs@cs.cmu.edu".  All project members and some of our
  23. more intense users read this list, and the right person will answer
  24. (assuming we can get mail to you).
  25.  
  26. On your original query, you wanted to know how to recompile CMU CL for a
  27. new platform other than the Sparc.  Well, there are some bootstrapping
  28. tricks involved in recompiling the system -- we can elaborate if necessary.
  29. But the larger issue is that you can't just recompile this thing for some
  30. other CPU.
  31.  
  32. Unlike AKCL, CMU CL is not just a vanilla, machine-independent C program.
  33. There's a native-code compiler, so porting to a new platform requires
  34. writing a new compiler back-end, plus some low-level routines, plus maybe
  35. some serious tuning and re-design of the internal data formats to get full
  36. efficiency from a new platform.  William Lott, our chief porting wizard,
  37. has got this down to a few weeks for RISC machines running something close
  38. to Mach/Unix, but it would take considerably longer for anyone else.
  39.  
  40. Porting to other operating systems is also a hassle, since we depend on
  41. some of the memory management facilities in Mach.  SunOS and OSF/1 have
  42. these same facilities, more or less; Ultrix, the old HP/UX, and other
  43. bsd-based Unix systems do not.  We could port to bsd, with some months of
  44. effort and a lot of code reorganization, but since all these systems are
  45. allegedly being phased out in favor of OSF or some other more modern
  46. version of Unix, we've decided to wait and let the world come to us.  In
  47. the case of DEC, there have been a lot of delays in getting out their
  48. OSF-like version of Ultrix.
  49.  
  50. We haven't done a lot of ports because there aren't a lot of widely-used
  51. machines out there with Mach/OSF-style operating systems, and because for
  52. some of the ports that we could easily do (SGI Indigo, IBM RS/6000),
  53. we don't have the hardware available locally to support a porting effort.
  54. Several of our external users have asked about a NeXT port, but porting to
  55. the Motorola 68K would be more difficult than porting to yet-another-RISC,
  56. and of little long-term value if NeXT switches to a RISC CPU in the near
  57. future.  In any case, we don't have any of those machines to work on
  58. either.
  59.  
  60. So for now the selection is Sparc under SunOS and Mach, Decstation (MIPS
  61. CPU) under Mach/OSF, and the old, slow IBM RT under Mach (which we happen
  62. to have a lot of).
  63.  
  64. -- Scott
  65.