home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / gnu / misc / discuss / 4313 < prev    next >
Encoding:
Text File  |  1993-01-08  |  3.0 KB  |  78 lines

  1. Newsgroups: gnu.misc.discuss
  2. Path: sparky!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!nntp!sja
  3. From: sja@snakemail.hut.fi (Sakari Jalovaara)
  4. Subject: Re: Public Domain C Compiler?
  5. In-Reply-To: mcastle@cs.umr.edu's message of Wed, 6 Jan 1993 16:12:45 GMT
  6. Message-ID: <SJA.93Jan8182853@lk-hp-19.hut.fi>
  7. Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
  8. Nntp-Posting-Host: lk-hp-19.hut.fi
  9. Organization: Helsinki University of Technology, Finland
  10. References: <2B4A0FD5.FD6B@tct.com> <C0FuFu.o41@austin.ibm.com> <1993Jan6.161245.4926@umr.edu>
  11. Date: 08 Jan 93 16:28:52 GMT
  12. Lines: 64
  13.  
  14.  
  15. > I've seen a few posts here [...] I have doubts to their dedication
  16. > to the project.
  17.  
  18. Well, "dedication"...  I've been writing a free C compiler as a
  19. hobby.  I can't guarantee eternal "dedication"; so far I've stuck
  20. with it.  It really is an interesting and challenging project.
  21.  
  22. The front end is 95% done (doesn't it always seem like your programs
  23. are 95% finished?); a back end is early stages of construction.
  24.  
  25. (With suitable definitions of "back end" & "front end".)
  26.  
  27. An ANSI C test suite (way over 50% of my effort so far) is shaping
  28. up very nicely.
  29.  
  30. If you want a compiler in a shiny plastic wrapper, a glossy
  31. manual with pictures of cute furry animals explaining its use,
  32. delivered to your door by Federal Express -- shop elsewhere.
  33.  
  34. > Writing a compiler is a daunting project
  35.  
  36. "Daunting" is a bit strong; it's not _that_ difficult.  Depends;
  37. if you want to put in every conceivable optimization and port
  38. it to everything from vector processors to toasters...
  39.  
  40. A reasonably reliable (better than what you usually get in UN*X)
  41. compiler with a couple of back ends is certainly doable.
  42.  
  43. > Writing a portable compiler, even more so.
  44.  
  45. This isn't *too* bad either.  Depends on the machine specific
  46. optimizations you want to do; code generation is not that
  47. difficult given the research that has been published over the
  48. last 10..15 years.
  49.  
  50. Debugging information is a pain.  I don't think I'll be able
  51. to do that for more than a few machines by myself.
  52.  
  53. Otherwise, I'd venture to guess that the portability problems
  54. of e.g. tcsh are far greater than those of a well written compiler.
  55.  
  56. > it becomes quite a logistic problem to try to incorporate changes
  57. > into the original compiler in a coherent manner.
  58.  
  59. Depends...  If you just want to merge machine dependent changes (code
  60. generator generator descriptions etc) it isn't too bad.  If you
  61. incorporate optimizations and language extensions you'll have more
  62. work.
  63.  
  64. Incorporating changes you can't test is a lot of work but others
  65. seem to be coping (tcsh? elm?)  I'm looking forward to it if I
  66. ever get there.
  67.  
  68. You know, there is a theory that says that free software tends to be
  69. easy to maintain because there are so many people who can help with it.
  70. If the original authors can't continue working on it, the theory says
  71. someone else can adopt it.  Maybe that is even true!
  72.  
  73. > I just really doubt one person could do it and remain sane
  74.  
  75. Thanks a lot, sunshine :-)  I've always been halfway over the hill
  76. so this doesn't bother me.
  77.                                     ++sja
  78.