home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / scheme / c / 101 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  2.1 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!yale.edu!yale!mintaka.lcs.mit.edu!ai-lab!zurich.ai.mit.edu!gjr
  2. From: gjr@zurich.ai.mit.edu (Guillermo J. Rozas)
  3. Newsgroups: comp.lang.scheme.c
  4. Subject: Re: SPARC native code compiler
  5. Message-ID: <GJR.93Jan22090613@chamarti.ai.mit.edu>
  6. Date: 22 Jan 93 17:06:13 GMT
  7. References: <XJAM.93Jan21200905@cork.CS.Berkeley.EDU>
  8. Reply-To: gjr@zurich.ai.mit.edu
  9. Distribution: inet
  10. Organization: M.I.T. Artificial Intelligence Lab.
  11. Lines: 39
  12. NNTP-Posting-Host: chamartin.ai.mit.edu
  13. In-reply-to: xjam@cork.CS.Berkeley.EDU's message of 21 Jan 93 20:09:05
  14.  
  15. In article <XJAM.93Jan21200905@cork.CS.Berkeley.EDU> xjam@cork.CS.Berkeley.EDU (The Crossjammer) writes:
  16.  
  17. |   From: xjam@cork.CS.Berkeley.EDU (The Crossjammer)
  18. |   Newsgroups: comp.lang.scheme.c
  19. |   Date: 21 Jan 93 20:09:05
  20. |
  21. |   I'm interested in porting the native code compiler to the SPARC
  22. |   architecture if it hasn't been done already. Who should I contact?
  23.  
  24. To our knowledge, there is no back end for the Sparc architecture.
  25.  
  26. Depending on how much time you have, there are two possibilities.
  27.  
  28.  
  29. Option A: Write a full native port.  To find out how to do this, ftp the
  30. compiler porting guide from
  31.  
  32. altdorf.ai.mit.edu:archive/scheme-7.2/compdoc.tar.Z
  33.  
  34. It is very slightly out of date, but the differences should not be
  35. important.
  36.  
  37. This will take a considerable amount of time (~3 weeks for an expert).
  38.  
  39.  
  40. Option B: We have a back end that generates C almost finished.  It is
  41. up enough to compile most of the runtime system (all but three files).
  42. The output is both larger and slower than the native version, but much
  43. faster than the interpreter.  Besides some debugging and cleaning up
  44. of rough edges, one of the things that is missing is the ability to
  45. load compiled files dynamically -- right now it is all done
  46. statically, when the "microcode" is generated.  You could have a
  47. working system much faster if you took this approach.
  48.  
  49.  
  50. Even if you decide to go with option A, you may be interested in
  51. option B as a reference.  The RTL rules expand into macroized-C
  52. fragments rather than any individual architecture, so they may be
  53. easier to understand.
  54.