home *** CD-ROM | disk | FTP | other *** search
/ cs.rhul.ac.uk / www.cs.rhul.ac.uk.zip / www.cs.rhul.ac.uk / pub / rdp / old_versions / rdp1_4.doc < prev    next >
Text File  |  1995-02-14  |  12KB  |  256 lines

  1. The fourth maintenance release of RDP (version 1.4) is now available via ftp
  2. from cscx.cs.rhbnc.ac.uk (134.219.200.45) in directory /pub/rdp. Get
  3. rdp1_4.zip if you are an MS-DOS user or rdp1_4.tar if you are a Unix user.
  4.  
  5. The major changes at this release centre around the rewritten support library.
  6. In particular the set module now handles dynamically resizable sets and the
  7. symbol table manager allows multiple tables with arbitrary data. Several RDP
  8. directives have been replaced or deleted to reflect changes in the library.
  9.  
  10. A fuller list of changes will be found at the end of this message
  11.  
  12. **** Here follows a thumbnail sketch of RDP ****
  13.  
  14. RDP - a recursive descent parser generator
  15.  
  16. RDP compiles attributed LL(1) grammars decorated with C-language semantic
  17. actions into recursive descent compilers. RDP is written in strict ANSI C and
  18. produces strict ANSI C. RDP was developed using Borland C 3.1 on a PC and has
  19. also been built with no problems on Alpha/OSF-1, DECstation/Ultrix, Sun
  20. 4/SunOS, Linux and NetBSD 0.9 hosts all using GCC. The definition of strict
  21. ANSI here means  compiling with
  22.  
  23. gcc -Wmissing-prototypes -Wstrict-prototypes -fno-common -Wall -ansi -pedantic
  24.  
  25. and getting no warning messages. 
  26.  
  27. RDP also compiles with Borland Turbo-C and Microsoft C.
  28.  
  29. RDP is C++ `clean' i.e. there are no identifiers used that clash with C++
  30. reserved words. RDP generated code has been used with g++ applications, and
  31. compiles with g++ and the Borland C++ (as opposed to ANSI) compiler.
  32.  
  33. RDP itself and the language processors it generates use standard symbol, set
  34. memeory management, text buffering and scanner modules. The RDP scanner is
  35. programmed by loading tokens into a symbol table at the start of each run.
  36. In principle, the RDP scanner can be used to support runtime extensible
  37. languages, such as user defined operators in Algol-68, although nobody has had
  38. the nerve to try this yet.
  39.  
  40. RDP produces complete runnable programs with built-in help information and
  41. command line switches that are specified as part of the EBNF file. In this
  42. sense RDP output is far more shrink-wrapped than the usual parser generators
  43. which helps beginning students. RDP generates itself (you mean you use a 
  44. parser generator which _isn't_ written in itself?) which is a nice
  45. demonstration of the bootstrapping technique used for porting compilers to new
  46. architectures.
  47.  
  48. I wrote RDP because in October '94 I started giving a course on compiler
  49. design. I don't think the world needs another course on parsing techniques and
  50. am really interested in code generation for exotic processors, so I tried to
  51. produce a compact parser generator that would enable undergraduates to rip
  52. through the syntax and standard code generation parts of the syllabus in a few
  53. weeks, thus leaving me time to get into the black arts of code scheduling and
  54. optimisation.
  55.  
  56. What you get.
  57.  
  58. o A set-handling package that supports dynamically sizable sets.
  59.  
  60. o A hash-coded symbol table with support for multiple symbol tables, 
  61.   nested scope rules and arbitrary user data.
  62.  
  63. o A standard text buffering package with integrated messaging utilities that 
  64.   are used for all communication with the user.
  65.  
  66. o A set of wrapper functions for the standard C memory allocation routines
  67.   with built in fatal error handling for out of memory errors.
  68.  
  69. o A programmable high-speed scanner with integrated error handling and
  70.   hooks for macros (RDP is being used to generate assemblers for two novel
  71.   microprocessors in addition to the usual applications of LL(1) parsers).
  72.  
  73. o The machine generated source for the RDP translator. RDP checks that
  74.   the source grammar is LL(1) and explains exactly why a non-LL(1) grammar
  75.   is unacceptable. RDP does not attempt to rework a grammar by itself.
  76.  
  77. o The decorated EBNF file describing RDP that was processed by the RDP 
  78.   executable to produce its own source code. This is good for boggling 
  79.   undergraduate's minds with.
  80.  
  81. o Decorated EBNF files for the languages Mini and Mini-plus that are used as
  82.   examples in the user manual.
  83.  
  84. o An EBNF file describing ISO-Pascal which generates a parser for the Pascal 
  85.   language (this is still under construction - a working grammar for Pascal
  86.   is included but it is not guaranteed to be ISO standard).
  87.  
  88. o An EBNF file describing ANSI C which generates a parser for the C programming
  89.   language (this is still under construction). 
  90.  
  91. o Sources, makefiles and Borland 3.1 project files for everything which
  92.   you may use freely on condition that you send copies of any modifications,
  93.   enhancements and ill-conceived changes you might make back to me so that
  94.   I can improve RDP.
  95.  
  96. o User and library support manuals
  97.  
  98. What you don't get.
  99.  
  100. o Tutorial information on parsing and compiling (try Wirth's Algorithms +
  101.   Data Structures = Programs, Chapter 5 or your favourite compiler book).
  102.   Maybe one day there'll be a book by me. In a future release I will include
  103.   the slides and notes from my compilers course.
  104.  
  105. o Warranties. This code has only just escaped from my personal toolkit.
  106.   I've put a lot of effort into making it fit for others to use, but in
  107.   the very nature of compiler compilers it is hard to test all the angles,
  108.   and the Garbage In - Garbage Out principle holds to the highest degree:
  109.   if you write ill-formed semantic actions you won't find out until you try
  110.   and compile the parser that RDP wrote for you. On the plus side, RDP has
  111.   now been used pretty ferociously by lots of people and has stood up very 
  112.   well. It does seem to be pretty stable, and I will continue to respond to
  113.   bug reports.
  114.  
  115.                                      Adrian
  116.  
  117.  
  118.  
  119. ** RDP release version 1.40 flyer. Adrian Johnstone 30 January 1995 **
  120.  
  121. This is the RDP V1.40 release distribution. To install RDP look in the
  122. makefile and ensure that the blocks of options at the top are commented out   
  123. correctly for your compiler and operating system. Then type 'make' (or 'nmake'
  124. if you are a Microsoft  compiler user) and stand well back.           
  125.      
  126. If you use an ANSI compiler then you should be able to build RDP after you
  127. have uncommented suitable compiler switch options in the makefile. I'd really
  128. like to hear about any problems you have with other MS-DOS or Unix C
  129. compilers.   
  130.                      
  131. If you have a non-ANSI compiler, then the only part of the code that might
  132. cause you problems is that several of the data structures use bit fields to
  133. store flags. You can rework the code to use #define'd masks in the traditional 
  134. way if you have enough patience.
  135.       
  136. Further documentation may be found in Postscript form in subdirectory 'rdp_doc'.
  137.  
  138. I'd like to thank the many people who have tried RDP and sent me encouraging
  139. messages, suggestions for improvements and bug reports, in particular Andy
  140. Betts (previously of UCL, now at Inmos) and my students on course CS347 
  141. (Compilers and code generation) at RHUL.
  142.  
  143. ** Improvements in this version include **
  144.  
  145. NEW FEATURES AND CHANGES
  146.  
  147. 1. The RDP support library has been completely rewritten and now comprises
  148. modules memalloc, scan, scanner, set, symbol and textio.
  149.  
  150. 2. The new symbol table handler allows multiple tables to be declared with
  151. arbitrary user data. 
  152.  
  153. 3. A new SYMBOL_TABLE directive allows symbol tables to be specified from
  154. within the EBNF file. 
  155.  
  156. 4. The HASH_PRIME and HASH_SIZE directives have been removed since their
  157. functions are subsumed into the new SYMBOL_TABLE feature.
  158.  
  159. 5. The memory allocation routines from module crash have been moved to a new
  160. support module called memalloc.c. A versions of realloc and free have been 
  161. added, and the size parameter has been reinstated on calloc.
  162.  
  163. 6. Module scan now contains just the token testing and scanner error routines.
  164. Error messages are generated at run time, significantly reducing the size of 
  165. the static data segment.
  166.  
  167. 7. The actual scanner is in module scanner. In a future release the scanner 
  168. be written into the parser file by rdp. This version still uses essentially
  169. the old hard wired scanner.
  170.  
  171. 8. A brand new set handling package which supports dynamically sized sets
  172. has been added.
  173.  
  174. 9. The SET_SIZE directive has been deleted as it is no longer needed since
  175. sets can expand to arbitrary size.
  176.  
  177. 10. The `out of tokens' error message has been removed because sets can now
  178. expand dynamically, so you can never run out of token space.
  179.  
  180. 11. The messaging routines from modules scan and crash have been completely
  181. reworked and moved to a module called textio.
  182.  
  183. 12. Support module crash has been deleted.
  184.  
  185. 13. The error message generated by left recursive productions has been enhanced
  186. to print out the chain of productions involved in the left recursion.
  187.  
  188. 14. Parser syntax error messages are now generated at run time, significantly
  189. reducing the size of the string segment in RDP generated parsers.
  190.  
  191. 15. The INTERPRETER directive has been removed, because at V2.00 interpreter
  192. support will be via AST's.
  193.  
  194. 16. Interpreter support (read ahead of the whole file) has been removed from
  195. the scanner.
  196.  
  197. 17. Token names are now of the form T__xxx (i.e. with two consecutive
  198. underscores). The P_yyy primitive tokens are now named T__yyy in preparation
  199. for the new scanner support in version 2.00.
  200.  
  201. 18. A set of library support test routines is provided in subdirectory test.
  202.  
  203. 19. Strings returned from the STRING, STRING_ESC and so on primitives no
  204. longer have a leading header byte. RDP maintains tokens and production names in
  205. separate tables, removing the need for this disambiguation kludge.
  206.  
  207. 20. A simple assembler called nasm4 has been added to the distribution. A paper
  208. describing the target architecture is in rdp_doc.
  209.  
  210. **** Features for future versions
  211.  
  212. Version 2.00 will support scanner productions which supersede the various
  213. programmable tokens used at the moment. RDP will then write out a customised
  214. scanner for each language in exactly the same way that it currently writes out
  215. parsers. These generated scanners will look just like the existing scanner
  216. (i.e. they will NOT be DFA based) so that they can be debugged easily. A set
  217. of scanner productions roughly equivalent to the current scanner will be
  218. supplied.
  219.  
  220. As part of the scanner production support, subproductions comprising a list
  221. of alternates each of which is exactly one terminal long will automatically
  222. be translated into a set of such tokens. NOT and wildcard operators will be
  223. provided.
  224.  
  225. Version 2.00 will also offer some new grammar writing tools. In particular, I
  226. intend to enhance the < > construct so as to allow specification of maximum
  227. and minimum iteration counts, and redefine all other constructs in terms of
  228. this  new mechanism, I also hope to support permutation phrases, as described
  229. in a recent edition of LOPLAS.  
  230.  
  231. There will be some elementary support for the construction of abstract syntax
  232. trees, probably in the form of some semantic action macros that implement
  233. common construction operations. RDP itself will be rewritten using this
  234. standard AST format rather than the mix of special data structures presently
  235. used.
  236.  
  237. Perhaps at V2.00, you will be able to selectively allow backtracking so
  238. allowing LL(k) grammars to be parsed. If you need this a lot you should be
  239. looking at PCCTS or PRECC not RDP.
  240.  
  241. Other suggestions for improvements are welcome.
  242.  
  243. Finally (surprise, surprise) a textbook on code generation for modern
  244. processors, using RDP to construct the compiler front ends, will appear
  245. eventually. Anybody interested in beta-testing the book might like to get in
  246. touch, but we're not expecting to make much progress on it until early Summer
  247. 1995.
  248.  
  249. ***
  250. Comments, queries and requests for code to
  251.  
  252. Smail: Dr Adrian Johnstone, Dean of Science, Computer Science Department, 
  253.        Royal Holloway, University of London, Egham, Surrey, TW20 0EX, UK.
  254.  
  255. Email: adrian@dcs.rhbnc.ac.uk  Tel: +44 (0)1784 443425  Fax: +44 (0)1784 443420
  256.