home *** CD-ROM | disk | FTP | other *** search
/ cs.rhul.ac.uk / www.cs.rhul.ac.uk.zip / www.cs.rhul.ac.uk / pub / rdp / rdp_cs3470.tar / 00readme.1_5 next >
Text File  |  1998-05-07  |  19KB  |  411 lines

  1. The fifth maintenance release of RDP (version 1.5) is now available via ftp 
  2. from ftp.cs.rhbnc.ac.uk in directory /pub/rdp. Get rdp1_5.zip if you are an
  3. MS-DOS user or rdp1_5.tar if you are a Unix user. You can also access the
  4. ftp server via the rdp web site at      
  5.  
  6.       http:\\www.dcs.rhbnc.ac.uk\research\languages\rdp.shmtl
  7.  
  8. This will be the last release of RDP version 1. A new version of RDP
  9. which targets LL(oo) parsing (leftmost parsing with arbitrary
  10. backtracking) will appear in due course: backwards compatibility with
  11. RDP version 1 is not absolutely guaranteed, but I'll do my best.
  12.  
  13. This release includes the following new features
  14.  
  15.  - an new iterator operator,
  16.  
  17.  - new positive closure syntax,
  18.  
  19.  - a new command line argument processing library,
  20.  
  21.  - a new graph construction and manipulation library with support for the VCG 
  22.    (Visualisation of Compiler Graphs) tool so that you can look at your data 
  23.    structures under Unix/X-windows and Microsoft Windows,
  24.  
  25.  - improvements to the formatting of error messages,
  26.  
  27.  - scanner lookahead for the REAL primitive,
  28.  
  29.  - support for underscores in INTEGER and REAL literals,
  30.  
  31.  - a new naming convention that removes the conflict between some C++
  32.    implementations and the double underscore naming convention,
  33.  
  34.  - support for integer literal, real literal and string literal parameters to
  35.    parser functions,
  36.  
  37.  - improvements to the entry code for parser functions so that semantic
  38.    actions behave sensibly for productions with optional bodies,
  39.  
  40.  - extensive new facilities for constructing and manipulating derivation trees 
  41.  
  42.  - new debugging options that help trace a parser's behaviour,
  43.  
  44.  - updated user and support library manuals,
  45.  
  46.  - a new tutorial manual,
  47.  
  48.  - a new case study manual which describes two interpreters, two compilers and
  49.    a C pretty printer
  50.  
  51. A fuller list of changes will be found at the end of this message.
  52.  
  53. *** VERY IMPORTANT WARNING
  54.  
  55. One seriously non-backwards compatible change involving the <...> construct
  56. has been incorporated in version 1.5. Read the compatibility section below 
  57. before processing a pre-version 1.5 grammar that includes instances of the
  58. <...> with this version of RDP. All occurences of <...>'x' MUST be replaced
  59. with (...)@'x' because the semantics of the <...> construct have been changed.
  60.  
  61. *** END OF VERY IMPORTANT WARNING
  62.  
  63. **** Here follows a thumbnail sketch of RDP ****
  64.  
  65. RDP - a recursive descent parser generator with one symbol of lookahead
  66.  
  67. RDP compiles attributed LL(1) grammars decorated with C-language
  68. semantic actions into recursive descent parsers. 
  69.  
  70. RDP is written in strict ANSI-C and produces strict ANSI-C. RDP was
  71. developed using Borland C++ versions 3.1 and 5.1 on a PC and has also
  72. been built with no problems on Alpha/OSF-1, DECstation/Ultrix, HP
  73. Apollo/HPUX, Sun 4/SunOS, Solaris, Linux and NetBSD 0.9 hosts all using
  74. gcc and g++ as well as variety of vendor's own compilers. RDP also
  75. compiles for MS-DOS under Microsoft C V7.0, gcc (using the djpgg port)
  76. and several other compilers. I have reports of successful builds on Mac,
  77. Amiga and the Acorn Archimedes.
  78.  
  79. The definition of strict ANSI here means compiling under gcc with
  80.  
  81. gcc -Wmissing-prototypes -Wstrict-prototypes -fno-common -Wall -ansi -pedantic
  82.  
  83. and getting no warning messages.
  84.  
  85. RDP is C++ `clean' i.e. there are no identifiers used that clash with C++
  86. reserved words. RDP generated code has been used with g++ applications, and
  87. compiles with g++ and the Borland C++ (as opposed to ANSI C) compiler.
  88.  
  89. RDP itself, and the language processors it generates, use standard library
  90. modules to manage symbol tables, sets, graphs, memory allocation, text
  91. buffering, command line argument processing and scanning. The RDP scanner is
  92. programmed by loading tokens into a symbol table at the start of each run. In
  93. principle, the RDP scanner can be used to support runtime extensible
  94. languages, such as user defined operators in Algol-68, although nobody has had
  95. the nerve to try this yet.
  96.  
  97. RDP produces complete runnable programs with built-in help information and
  98. command line switches that are specified as part of the EBNF file. In this
  99. sense RDP output is far more shrink-wrapped than the usual parser generators
  100. which helps beginners. 
  101.  
  102. The RDP text buffering routines automatically handle nested files, error
  103. message reporting and text data buffering to provide an efficient general
  104. purpose front end. This is also a great help to new users since writing
  105. efficient (and correct) text buffering and scanning routines from scratch is,
  106. in my experience, harder than it appears.
  107.  
  108. The RDP graph handling package provides a general framework for building
  109. graph data structures that may then be output in a form suitable for display 
  110. with the VCG (Visualisation of Compiler Graphs) tool. RDP generated parsers
  111. can be set to automatically build derivation trees in a form suitable for
  112. human viewing. VCG runs on Windows 3.1, Windows-95 and Unix/X-windows systems.
  113. We are grateful to the author of VCG for permission to supply VCG with RDP: you
  114. can fetch a copy of VCG from the home FTP site for RDP 
  115. (ftp://ftp.cs.rhbnc.ac.uk/pub/rdp)
  116.  
  117. RDP generates itself (you mean you use a parser generator which _isn't_
  118. written in its own source language?) which is a nice demonstration of
  119. the bootstrapping technique used for porting compilers to new
  120. architectures.
  121.  
  122. I wrote RDP because in October '94 I started giving a course on compiler
  123. design. I am mainly interested in code generation for exotic processors,
  124. so I tried to produce a compact parser generator that would enable
  125. undergraduates to rip through the syntax and standard code generation
  126. parts of the syllabus in a few weeks, thus leaving me time to get into
  127. the black arts of code scheduling and optimisation.
  128.  
  129. What you get.
  130.  
  131. - The machine generated source for the RDP translator (rdp.c). RDP checks that
  132.   the source grammar is LL(1) and explains exactly why a non-LL(1) grammar is 
  133.   unacceptable. This version of RDP does not attempt to rework a grammar by
  134.   itself.
  135.  
  136. - The decorated EBNF file describing RDP that was processed by the RDP
  137.   executable to produce its own source code (rdp.bnf). This is good for
  138.   boggling undergraduate's minds with.
  139.  
  140. - Decorated EBNF files for the languages minicalc, minicond, miniloop
  141.   and minitree that are used as examples in the case study manual. The 
  142.   languages illustrate the development of a simple programming language 
  143.   by way of a syntax checker, two interpreters and finally two syntax-directed
  144.   compilers that produces assembly language for a mythical machine called
  145.   MVM (Mini Virtual Machine). One of the compilers is a single pass
  146.   translator and the other uses a tree-based intermediate form.
  147.  
  148. - The decorated EBNF file for mvmasm, an assembler for the language
  149.   produced by the above compilers along with a simulator called mvmsim for the
  150.   resulting executable files.
  151.  
  152. - An EBNF file describing a not particularly standard Pascal with some
  153.   extensions for Turbo Pascal which generates a fully working parser.
  154.  
  155. - An ANSI C pretty printer written using RDP
  156.  
  157. - A set of functions to automate the handling of command line arguments (arg.c).
  158.  
  159. - Routines to implement general graph data structures (graph.c).
  160.  
  161. - A set of wrapper functions for the standard C memory allocation routines
  162.   with built in fatal error handling for out of memory errors (memalloc.c).
  163.  
  164. - A programmable scanner with integrated error handling (scan.c and scanner.c).
  165.  
  166. - A set-handling package that supports dynamically sizable sets (set.c).
  167.  
  168. - A hash-coded symbol table with support for multiple symbol tables,
  169.   nested scope rules and arbitrary user data (symbol.c).
  170.  
  171. - A standard text buffering package with integrated messaging utilities that
  172.   are used for all communication with the user (textio.c).
  173.  
  174. - Sources and makefiles for everything which you may use freely on condition
  175.   that you send copies of any modifications, enhancements and ill-conceived
  176.   changes you might make back to me so that I can improve RDP.
  177.  
  178. - User, library support, tutorial and case study manuals.
  179.  
  180. What you don't get.
  181.  
  182. - Warranties. This code has only just escaped from my personal toolkit.
  183.   I've put a lot of effort into making it fit for others to use, but in
  184.   the very nature of compiler compilers it is hard to test all the angles,
  185.   and the Garbage In - Garbage Out principle holds to the highest degree:
  186.   if you write ill-formed semantic actions you won't find out until you try
  187.   and compile the compiler that RDP wrote for you. On the plus side, RDP has
  188.   now been used pretty ferociously by lots of people and has stood up very
  189.   well. It does seem to be pretty stable, and I will continue to respond to
  190.   bug reports.
  191.  
  192. ** RDP release version 1.50 flyer. Adrian Johnstone 20 December 1997 **
  193.  
  194. This is the RDP V1.50 release distribution. To install RDP look in the
  195. makefile and ensure that the blocks of options at the top are commented out
  196. correctly for your compiler and operating system. Then type 'make' (or 'nmake'
  197. if you are a Microsoft  compiler user) and stand well back.
  198.  
  199. If you use an ANSI compiler then you should be able to build RDP after you
  200. have uncommented suitable compiler switch options in the makefile. I'd really
  201. like to hear about any problems you have with other MS-DOS or Unix C
  202. compilers - my aim is to make RDP as portable as TeX (some hope).
  203.  
  204. Further documentation may be found in Postscript and DVI forms in subdirectory
  205. 'manuals'.
  206.  
  207. We'd like to thank the many people who have tried RDP and sent me encouraging
  208. messages, suggestions for improvements and bug reports, in particular Andy
  209. Betts (previously of UCL, now at Inmos), my students on course CS347
  210. (compilers and code generation) at RHUL.
  211.  
  212. ** Improvements in this version include **
  213.  
  214. NEW FEATURES
  215.  
  216. 1. A new iteration operator @ has been introduced which subsumes all of the
  217. EBNF brackets which are now represented internally as special cases of the @
  218. operator. The old <...>'x' construct should now be written as (...)@'x'.
  219.  
  220. 2. <...> is now used to represent positive closure (one or many).
  221.  
  222. 3. Scanner lines are now echoed after error messages have been written. This
  223. allows a more compact `pointing' notation, and the delayed echo makes it
  224. possible to insert text before the echoed line which is useful for assemblers,
  225. as demonstrated by the mvmasm assembler described in the tutorial manual.
  226.  
  227. 4. A new scanner primitive CHARACTER has been added that reads a single stropped,
  228. quoted character.
  229.  
  230. 5. LL(1) errors detected during grammar parsing are now flagged in the parser
  231. source code, so that if you are stepping through a parser using a debugger
  232. you will be reminded that something odd is about to happen. Look in pascal.c
  233. (which is created during a make all) for an example.
  234.  
  235. 6. A new option -P has been added to RDP. Parsers generated with this option
  236. issue information messages on entry and exit from each parser function: this
  237. can be useful for tracing parser operation but as you might expect it produces
  238. a lot of output.
  239.  
  240. 7. A new support library module (arg.c) has been added to handle processing of
  241. command line arguments in a standard way. New directives ARG_BOOLEAN,
  242. ARG_NUMERIC and ARG_STRING have been added to RDP and the OPTION directive has
  243. been dropped. The old OPTION directive has been dropped.
  244.  
  245. 8. A new support library module (graph.c) has been added which handles general
  246. graph datastructures. 
  247.  
  248. 9. The graph library can output any graph in a form suitable for viewing with
  249. the VCG (Visualisation of Compiler Graphs) tool written by
  250. You can fetch a copy of VCG for Unix/X-windows or MS-Windows systems from 
  251. ftp://ftp.dcs.rhbncs.ac.uk/pub/rdp. 
  252.  
  253. 10. Three new directives TREE, EPSILON_TREE and ANNOTATED_EPSILON_TREE have been 
  254. added that cause parsers to build derivation trees using the new graph library.
  255.  
  256. 11. Node promotion operators (^, ^^, ^^^ and ^_) have been added that
  257. allow the standard derivation trees to be modified during construction
  258. into intermediate tree forms suitable for use with multiple pass
  259. compilers. This notation is rather experimental and we would very much
  260. like to hear users' opinions on its ease or difficulty of use. (See
  261. Chapters 9 and 10 of the user manual and Chapter 8 of the case study
  262. manual for descriptions of the new tree features.)
  263.  
  264. 12. A new option -V<name> has been added to parsers generated with the 
  265. TREE directive. At completion of a parse that parser will dump a VCG
  266. compatible description of the derivation tree to <name>. You can then
  267. use the VCG tool under MS-Windows or Unix/X-windows to view the graph.
  268.  
  269. 13. Support for parameter passing into parser functions (inherited attributes)
  270. has been improved. Formal parameter types may now include indirect types such
  271. as char*. In addition, literal strings, real and integer numbers can be used
  272. as actual parameters.
  273.  
  274. 14. Underscores may now be inserted into numeric literals in the style
  275. of Ada, so for instance 278_101_123 is a valid INTEGER literal.
  276.  
  277. 15. A new tutorial guide for new users has been added, covering the
  278. basic steps required to build a parser for a new language.
  279.  
  280. 16. A new case study manual has been added that describes the
  281. development of a family of language translators, culminating in a
  282. compiler that produces code for a virtual machine. An assembler and
  283. simulator for the target machine are also provided.
  284.  
  285. FIXES and ENHANCEMENTS
  286.  
  287. 17. All RDP indentifiers of the form xxx__yyy are renamed to xxx_yyy to avoid
  288. clashes with some C++ implementations (sigh). RDP now checks explicitly for
  289. identifiers that begin arg_, graph_, mem_, rdp_, scan_ set_, sym_ or text_ and
  290. issues an error message if it finds any so as to avoid clashes with built in
  291. identifer names. Sorry about this change, but I didn't know that the orginal
  292. AT&T C++ front end uses double underscore internally rather a lot. Teach me to
  293. read the book more carefully.
  294.  
  295. 18. The set_print routine now takes a line length argument so that line breaks
  296. can be inserted in long lists. This feature is used to suppress the very long
  297. lines in set initialisation code that have been causing some editors to break.
  298.  
  299. 19. Parsers now exit at the end of a pass in which errors occur.
  300.  
  301. 20. The scanner now looks ahead when checking for a real to make sure things of
  302. the form 1..3 are reported as 1 followed by .. followed by 3 rather than 1.0
  303. followed by 0.3.
  304.  
  305. 21. The nasm assembler has been replaced by mvmasm, an assembler along
  306. with a simulator called mvmsim that takes the output from the miniloop
  307. and minitree compilers.
  308.  
  309. 22. An unterminated comment (i.e. an EOF appearing within a comment) is
  310. now detected and reported as: `fatal: EOF detected inside comment'.
  311.  
  312. 23. If the -T command line option is used to set the text buffer size to a
  313. value that is larger than the maximum value of size_t on the architecture, a
  314. warning message is issued and the type recast to size_t (which usually
  315. results in a wrap-around).
  316.  
  317. 24. symbol_lookup() now takes a scope argument.
  318.  
  319. 25. A new routine, symbol_find() allows common symbol update operations
  320. to be implemented in a single call.
  321.  
  322. 26. rdp productions returning void* (or for that matter void**...) results
  323. are now correctly implemented. Previously, the word void in a return type
  324. was enough to suppress generation of a result variable.
  325.  
  326. 27. Continuation tokens are now correctly added for tokens that appear
  327. in extended scanner primitives like STRING and COMMENT.
  328.  
  329. 28. Extended tokens (string and comment scanner primitives) now map to their
  330. opening tokens rather than the equivalent scanner primitive. This corrects a
  331. truly awful design error that I discovered the hard way when I wanted two
  332. alternates to start with different kinds of escaped strings. The fixes to the
  333. scanner are rather ugly.
  334.  
  335. 29. When using included files (i.e. nested called to text_open() ) a token
  336. was being lost in the parent file after the included file closed. This has been
  337. corrected.
  338.  
  339. 30. A production containing only references to the three non-visible COMMENT
  340. scanner primitives will not generate a `production never called' warning.
  341.  
  342. 31. Grammars containing only scanner primitives and nonterminals (i.e. grammars with
  343. no keywords) are now handled correctly.
  344.  
  345. 32. New functions have been added to the text library to get the current tabwidth
  346. setting and print strings as ANSI C character constants.
  347.  
  348. 33. Multiline comments are now returned correctly in the COMMENT...VISIBLE
  349. scanner primitives.
  350.  
  351. 34. The lexeme for INTEGER and REAL scanner primitives is now returned in the
  352. id field.
  353.  
  354. 35. The rdp_sourcefilename global variable is now updated to show the actual file
  355. used (after file type processing) rather than the name used on the command line.
  356.  
  357. 36. Generate and compiler date stamps are now correctly implemented.
  358.  
  359. NON-BACKWARDS COMPATIBLE CHANGES -- IMPORTANT!
  360.  
  361. 37. The <body> 'token' construct is now represented by (body)@'token'.
  362.  
  363. <body> on its own now represents the positive closure of body, that is
  364. body{body}. Very sorry about this. Be careful!
  365.  
  366. **** Features for future versions
  367.  
  368. This will be the last functionality release for RDP version 1, although
  369. I will put out bug fixes as necessary. For most of this year I have been
  370. building small prototypes of a system for performing rather more general
  371. recursive descent parsers. Sometime soon a new translator generator tool
  372. called PGT (the Permutation Grammar Tool) will appear.
  373.  
  374. PGT will support LL(oo) parsing, that is arbitrary backtracking will be
  375. applied where necessary.  In principle this will allow many more context
  376. free grammar to be parsed, but not necesarilly in linear time. You will
  377. be warned of any non-linearities.
  378.  
  379. PGT will support scanner productions which supersede the various
  380. programmable tokens used at the moment. A customised scanner for each
  381. language will then be written out for each language.
  382.  
  383. As part of the scanner production support, subproductions comprising a list
  384. of alternates each of which is exactly one terminal long will automatically
  385. be translated into a set of such tokens. NOT and wildcard operators will be
  386. provided.
  387.  
  388. The iteration operator @ will be enhanced to handle general iteration
  389. and permutation phrases.
  390.  
  391. Other suggestions for improvements are welcome.
  392.  
  393. ***
  394. Comments, queries and requests for code to Adrian Johnstone, address below.
  395.  
  396. ***
  397. Primary code author and joint author of manuals
  398.  
  399. Smail: Dr Adrian Johnstone, Computer Science Department, Royal Holloway, 
  400.        University of London, Egham, Surrey, TW20 0EX, UK.
  401.  
  402. Email: A.Johnstone@rhbnc.ac.uk  Tel: +44 (0)1784 443425  Fax: +44 (0)1784 443420
  403.  
  404. Joint authorship of manuals and chief code checker
  405.  
  406. Smail: Dr E Scott, Computer Science Department, Royal Holloway, 
  407.        University of London, Egham, Surrey, TW20 0EX, UK.
  408.  
  409. Web:   http:\\www.dcs.rhbnc.ac.uk\research\languages\index.html
  410. ***
  411.