lburg.1 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180
  1. .TH LBURG 1 "local \- 11/30/94"
  2. .\" $Id: lburg.1 145 2001-10-17 21:53:10Z timo $
  3. .SH NAME
  4. lburg \- lcc's code-generator generator
  5. .SH SYNOPSIS
  6. .B lburg
  7. [
  8. .I option
  9. ]...
  10. [ [
  11. .I input
  12. ]
  13. .I output
  14. ]
  15. .br
  16. .SH DESCRIPTION
  17. .PP
  18. .I lburg
  19. reads an lcc-style BURG specification from
  20. .I input
  21. and writes a pattern-matching code generator to
  22. .IR output .
  23. If
  24. .I input
  25. is `\-' or is omitted,
  26. .I lburg
  27. reads the standard input;
  28. If
  29. .I output
  30. is `\-' or is omitted,
  31. .I lburg
  32. writes to the standard output.
  33. .PP
  34. .I lburg
  35. accepts specifications that conform to the following EBNF grammar.
  36. Terminals are enclosed in single quotes or are
  37. given in uppercase, all other symbols are nonterminals or English phrases,
  38. {X} denotes zero or more instances of X, and [X] denotes an optional X.
  39. .PP
  40. .nf
  41. .RS
  42. .ft CW
  43. spec: `%{' configuration `%}' { dcl } `%%' { rule }
  44. [ `%%' C code ]
  45. dcl: `%start' nonterm
  46. `%term' { ID `=' INT }
  47. rule: nonterm `:' tree template [ C expression ]
  48. tree: term `(' tree `,' tree `)'
  49. term `(' tree `)'
  50. term
  51. nonterm
  52. nonterm: ID
  53. template: `"' { any character except double quote } `"'
  54. .RE
  55. .fi
  56. .PP
  57. Specifications are structurally similar to
  58. .IR yacc 's.
  59. Text between
  60. `\f(CW%{\fP'
  61. and
  62. `\f(CW%}\fP'
  63. is called the configuration section; there may be several such segments.
  64. All are concatenated and copied verbatim into the head of the output.
  65. Text after the second
  66. `\f(CW%%\fP',
  67. if any, is also copied verbatim into the output, at the end.
  68. .PP
  69. Specifications consist of declarations, a
  70. `\f(CW%%\fP'
  71. separator, and rules.
  72. Input is line-oriented; each declaration and rule must appear on a separate line,
  73. and declarations must begin in column 1.
  74. Declarations declare terminals \(em the operators in subject
  75. trees \(em and associate a unique, positive external symbol
  76. number with each one.
  77. Nonterminals are declared by their presence
  78. on the left side of rules. The
  79. \f(CW%start\fP
  80. declaration optionally declares a nonterminal as the start symbol.
  81. In the grammar above,
  82. \f(CWterm\fP
  83. and
  84. \f(CWnonterm\fP
  85. denote identifiers that are terminals and nonterminals.
  86. .PP
  87. Rules define tree patterns in a fully parenthesized prefix
  88. form. Every nonterminal denotes a tree.
  89. Each operator has a fixed
  90. arity, which is inferred from the rules in which it is used.
  91. A chain rule is a rule whose pattern is another nonterminal.
  92. If no start symbol is declared, the nonterminal defined by the first rule is used.
  93. .PP
  94. Each rule ends with an expression that computes the cost of matching
  95. that rule; omitted costs
  96. default to zero. Costs of chain rules must be constants.
  97. .PP
  98. The configuration section configures the output
  99. for the trees being parsed and the client's environment.
  100. As shown, this section must define
  101. \f(CWNODEPTR_TYPE\fP
  102. to be a visible typedef symbol for a pointer to a
  103. node in the subject tree.
  104. The labeller invokes
  105. \f(CWOP_LABEL(p)\fP,
  106. \f(CWLEFT\_CHILD(p)\fP, and
  107. \f(CWRIGHT\_CHILD(p)\fP
  108. to read the operator and children from the node pointed to by \f(CWp\fP.
  109. If the configuration section defines these operations as macros, they are implemented in-line;
  110. otherwise, they must be implemented as functions.
  111. .PP
  112. The matcher
  113. computes and stores a single integral state in each node of the subject tree.
  114. The configuration section must define a macro
  115. \f(CWSTATE_LABEL(p)\fP
  116. to access the state field of the node pointed to
  117. by \f(CWp\fP. It must be large enough to hold a pointer, and
  118. a macro is required because it is used as an lvalue.
  119. .PP
  120. .SH OPTIONS
  121. .TP
  122. .BI \-p \ prefix
  123. .br
  124. .ns
  125. .TP
  126. .BI \-p prefix
  127. Use
  128. .I prefix
  129. as the disambiquating prefix for visible names and fields.
  130. The default is `\f(CW_\fP'.
  131. .TP
  132. .B \-T
  133. Arrange for
  134. .sp
  135. .nf
  136. .ft CW
  137. void _trace(NODEPTR_TYPE p, int eruleno,
  138. int cost, int bestcost);
  139. .sp
  140. .fi
  141. .ft R
  142. to be called at each successful match.
  143. \f(CWp\fP
  144. identifies the node and
  145. \f(CWeruleno\fP
  146. identifies the matching rule; the rules are numbered
  147. beginning at 1 in the order they appear in the input.
  148. \f(CWcost\fP
  149. is the cost of the match and
  150. \f(CWbestcost\fP
  151. is the cost of the best previous match. The current match
  152. wins only if
  153. \f(CWcost\fP
  154. is less than \f(CWbestcost\fP.
  155. 32767 represents the infinite cost of no previous match.
  156. \f(CW_trace\fP must be declared in the configuration section.
  157. .SH "SEE ALSO"
  158. .IR lcc (1)
  159. .PP
  160. C. W. Fraser and D. R. Hanson,
  161. .IR A Retargetable C Compiler: Design and Implementation ,
  162. Benjamin/Cummings, Redwood City, CA, 1995,
  163. ISBN 0-8053-1670-1. Chapter 14.
  164. .PP
  165. C. W. Fraser, D. R. Hanson and T. A. Proebsting,
  166. `Engineering a simple, efficient code generator generator,'
  167. .I
  168. ACM Letters on Programming Languages and Systems
  169. .BR 1 ,
  170. 3 (Sep. 1992), 213-226.
  171. .br
  172. .SH BUGS
  173. Mail bug reports along with the shortest input
  174. that exposes them to drh@cs.princeton.edu.