The following instructions show how to go about starting a new back-end for a new language "XYZ" using the Java back-end as a basis.
All the functionality contained in the Java files in the antlr-3.1/runtime/Java/src/org/antlr/runtime directory is needed to create a full back-end. You must also copy from the code generation templates of another target, such as antlr-3.1/src/org/antlr/codegen/templates/Java/*.stg. Finally create antlr-3.1/src/org/antlr/codegen/XYZTarget.java if you need to override anything in Target.java, which you probably will.
But it is in fact pretty easy to get started:
lexer grammar T; options { language = XYZ; } ZERO: '0'; |
N.B: The name after the word "grammar" needs to be the same as the filename in which you save it, i.e. T.g.
Your ANTLR code generation target will consist of several files in the target language. A number of run-time support files that you'll create directly, and a number of files that ANTLR will generate (in the target language) as the result of the user's grammar being processed by ANTLR. These files are generated from StringTemplates
like ZYX.stg
above.
ANTLR looks for the presence of certain template files and templates. Some are required, some are optional.
The principle template file. The templates in this file are used to generate the Lexer, Parser and Tree Parser generated by the user's grammar.
Template Name |
Purpose |
Notes |
---|---|---|
outputFile |
Generates the target-language implementation of the recognizer. |
Required |
headerFile |
Generates the target-language header file for the recognizer. |
Optional |
block()
StringTemplateParameter Name |
Description |
---|---|
alts |
|
decls |
|
decision |
|
enclosingBlockLevel |
|
blockLevel |
|
decisionNumber |
|
maxK |
|
maxAlt |
|
description |
|
closureBlock()
StringTemplateParameter Name |
Description |
---|---|
alts |
|
decls |
|
decision |
|
enclosingBlockLevel |
|
blockLevel |
|
decisionNumber |
|
maxK |
|
maxAlt |
|
description |
|
outputFile()
StringTemplateFormal parameters:
Parameter Name |
Description |
---|---|
LEXER |
Boolean indicating that a Lexer is being generated. |
PARSER |
Boolean indicating that a Parser or Combined Lexer/Parser is being generated. |
TREE_PARSER |
Boolean indicating that a Tree Parser is being generated. |
actionScope |
|
actions |
A |
docComment |
|
recognizer |
The StringTemplate named "lexer", "parser", or "treeParser", depending on the type of recognizer being generated. |
name |
|
tokens |
|
tokenNames |
|
rules |
|
cyclicDFAs |
A |
bitsets |
|
buildTemplate |
Boolean |
buildAST |
Boolean |
rewriteMode |
Boolean |
profile |
Boolean |
backtracking |
Boolean |
synpreds |
A |
memoize |
Boolean |
numRules |
|
fileName |
|
ANTLRVersion |
String containing the version of the ANTLR tool generating this recognizer. |
generatedTimestamp |
String containing the current time. |
trace |
Boolean |
scopes |
|
superClass |
|
literals |
|
rule()
StringTemplateThe rule()
StringTemplate is instantiated by ANTLR's own grammar processing and added to the "rules" attribute. It takes the following parameters.
Parameter Name |
Description |
---|---|
ruleName |
The name of the rule as specified in the input grammar. |
ruleDescriptor |
The |
block |
|
emptyRule |
|
description |
|
exceptions |
|
finally |
|
memoize |
|
dfaState()
StringTemplateParameter Name |
Description |
---|---|
k |
|
edges |
|
eotPredictsAlt |
|
description |
|
stateNumber |
|
semPredState |
|
dfaLoopbackState()
StringTemplateA DFA state that is actually the loopback decision of a closure loop. If end-of-token (EOT) predicts any of the targets then it should act like a default clause (i.e., no error can be generated). This is used only in the lexer so that for ('a')*
on the end of a rule anything other than 'a'
predicts exiting.
Parameter Name |
Description |
---|---|
k |
|
edges |
|
eotPredictsAlt |
|
description |
|
stateNumber |
|
semPredState |
|