home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / unix / volume2 / basic / part0 next >
Encoding:
Internet Message Format  |  1986-11-30  |  4.9 KB
  1. From: ukma!david (David Herron, NPR Lover)
  2. Subject: A BASIC interpretor (part 0 of 4)
  3. Newsgroups: mod.sources
  4. Approved: john@genrad.UUCP
  5.  
  6. Mod.sources:  Volume 2, Issue 22
  7. Submitted by: ukma!david (David Herron)
  8.  
  9. About a month ago I posted a response saying that I had a BASIC
  10. interpretor I'd written (that it wasn't a working interpretor)
  11. and that I'd post it if anybody wanted to debug it.  Well, something
  12. in the offer must have sounded tempting since I got about 30 replies
  13. all saying yes.  So here it is.
  14.  
  15. Let me give a little bit of the history first.  About 3 years ago
  16. I was taking a course entitled something like "Minicomputer Management".
  17. Which, it was basically a smoke screen behind which to introduce students
  18. to the wonderful world on Unix.  (On 2 PDP-11/23's (not 23+) running
  19. Version 7 (now 2.9BSD)).  Two weeks before the end of class we were
  20. assigned to write a BASIC interpretor.  Nobody else finished it
  21. but me, but it took me a year and a half to get a working version.
  22. (I spent a lot of that time playing with different ideas for parsing).
  23.  
  24. I had it working.  But it was in two parts.  A parser which turned
  25. the BASIC programs into a stack based intermediate language, and
  26. the interpretor for the intermediate language.  There was no immediate
  27. type in program and run it capability.  You had to run ed, write the
  28. file, save it, convert it, THEN run it.  I really wanted to have
  29. the two parts in one piece, so I started improving it.
  30.  
  31. Unfortunately, about half way through improving the program I got
  32. hired for my current job.  (One of those student slave labor deals).
  33. And I never finished it.  I don't know the status of the code I am 
  34. sending.  It may be code from the first iteration, or it may be 
  35. from the current (now a year old) iteration.
  36.  
  37. There are three directories under here, as follows:
  38.  
  39.     bs2    This has sources which will make the two part
  40.         translator/interpretor I described above.  But I
  41.         don't know if the files will compile into a runnable
  42.         program or not.
  43.     bstest    Some basic programs and the output produced by the
  44.         translator.  It should help you in understanding
  45.         what the intermediate code should look like.
  46.     newbs    This is where I was working on the new interpretor.
  47.         I was trying to make bsgram.y produce EITHER
  48.         the ascii intermediate file, or an incore version
  49.         that could be run immediately.  I may also have
  50.         been trying to clean up the grammar some.
  51.  
  52. The intermediate language is intended to be much like FORTH.  It is not
  53. a full FORTH of course, butis much simplified.  I picked this route
  54. partly as a path of least resistance, and partly to try out an
  55. idea.   (I had a good description of how to build a FORTH, if you are
  56. interested look for the article in 1981 or 1982 of the IEEE Computer
  57. magazine).  Around that time I had an inspiration on a better way to
  58. implement languages.  I had recieved a strong lesson in the amount of
  59. work that was needed to implement a language on a new piece of
  60. hardware.  My idea is similar to the P-code method of implementing
  61. Pascal. Design a machine-independant intermediate language which is
  62. simple yet provides facilities needed by a language interpretor.  You
  63. would save a lot of time in porting languages to new hardware this way,
  64. especially if the intermediate language was easy to interpret.  I
  65. already knew that RPN was easy to interpret having worked with one
  66. previously.   And I could show myself that it was easy to convert an
  67. expression tree to an RPN expression.  So this looked good.
  68.  
  69. The idealistic form of this interpretor is simply an array of pointers
  70. to procedures which are called in order.  In actuality arguments to the
  71. routines are interspersed with the pointers.   The comments in the code
  72. try to make this clear.  This is (currently) the only documentation,
  73. and in some cases the code and the comments may not agree.  Remember
  74. that this is a work in progress that was never completed.  (But now
  75. that I'm thinking about it again, I see so many better ways of doing
  76. things,  I  may just give it another go.)
  77.  
  78. A quick word about efficiency and I'll get off this subject.  My
  79. standard quickie benchmark is the nearest equivalent to:
  80.  
  81.  
  82.          10 FOR I = 1 TO 10000 
  83.          20 NEXT I
  84.  
  85.  
  86. I ran this on both a TRS-80 Color Computer (it was handy) with floating
  87. point arithmetic, and my interpretor running on a LSI-11/23 with
  88. integer arithmetic.   They both took about 15  seconds to run this.
  89. As a first attempt I am pleased to have showed so well against seasoned
  90. professionals.  On the other hand, considering the differences in data
  91. types, and CPU speeds, should have given a two to three times
  92. difference.   (In the favor of the LSI-11).  There is one GLARING thing
  93. I should do when (if) I do this over.   I should not have the
  94. interpretor doing procedure calls for each instruction, but should have
  95. the main loop be a large switch statement.  This was an early design
  96. decision that I now regret.  I went with using the procedure calls
  97. because it seemed that I would end up with a less monolithic system.
  98.