home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / lisp / 2895 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.6 KB
  1. Path: sparky!uunet!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
  2. From: William.Lott@cs.cmu.edu
  3. Newsgroups: comp.lang.lisp
  4. Subject: Re: CMU-Lisp on 486 running Mach ?
  5. Message-ID: <0f2=FHG00jeiMrS8UM@cs.cmu.edu>
  6. Date: 16 Nov 92 22:58:59 GMT
  7. Article-I.D.: cs.0f2=FHG00jeiMrS8UM
  8. References: <1992Nov11.132604.19198@wavehh.hanse.de>
  9. Organization: Carnegie Mellon, Pittsburgh, PA
  10. Lines: 50
  11. In-Reply-To: <1992Nov11.132604.19198@wavehh.hanse.de>
  12.  
  13. cracauer@wavehh.hanse.de (Martin Cracauer) writes:
  14. > I wonder, if one can bring up the CMU Common Lisp from the sources on
  15. > a PC running Mach.
  16. > 
  17. > Anybody there, who knows ?
  18. > 
  19. > An e-mail address of someone at CMU, who likes to respond, would be
  20. > good, too.
  21. > 
  22. > Thanks
  23. >         Martin
  24. > -- 
  25. > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  26. > Martin Cracauer,    cracauer@wavehh.hanse.de
  27. > Waldstrasse 200, W-2000 Norderstedt, Germany
  28. > Tel.: +49 / 522 18 29, Fax.: +49 / 522 85 36
  29.  
  30. Random queries about CMUCL can be sent to cmucl-bugs@cs.cmu.edu.
  31.  
  32. A port to the 386/486 running MACH is currently in progress but is
  33. much more involved then a port to Yet Another Risc Machine would be
  34. because of the limited number of registers.  The biggest problem is
  35. that the garbage collector assumes that the register file can be
  36. partitioned into two sets, one that only over holds valid lisp
  37. descriptors that can be identified by the garbage collector and one
  38. that holds raw binary values that would confuse the garbage collector.
  39. Given that the x86 only has 8 registers, artificially constraining
  40. their use would result in horrible performance if not a total
  41. implementation nightmare.
  42.  
  43. We have figured out how to solve this problem, but it requires a
  44. rather significant change: the compiler is going to have to annotate
  45. the object code with information about what registers hold valid lisp
  46. objects (i.e. the liveness info) at various points in the code and
  47. then the garbage collector has to be taught that it can only GC at
  48. those points.
  49.  
  50. We've been planning to move to a generational garbage collector, and
  51. it seemed like a good idea to merge these two tasks together given
  52. that they both involve bashing on the garbage collector.  But other
  53. higher priority tasks keep pushing this one back.  I plan on resuming
  54. active work on the 386/486 port Real Soon Now, and should have an
  55. alpha system Soon After That.  In other words, don't expect anything
  56. before early next year, and that is even rather optimistic.  (Of
  57. course, if someone were to donate money and/or machines to our
  58. project, that would of course cause us to re-prioritize the various
  59. tasks at hand. :-)
  60.  
  61. -William Lott
  62. CMU Common Lisp Group
  63.