1 % file: .../doc/modifying.tex
3 % $Header: /cvs/Darwin/Security/SecuritySNACCRuntime/doc/modifying.tex,v 1.1.1.1 2001/05/18 23:14:10 mb Exp $
4 % $Log: modifying.tex,v $
5 % Revision 1.1.1.1 2001/05/18 23:14:10 mb
6 % Move from private repository to open source repository
8 % Revision 1.1.1.1 1999/03/16 18:05:54 aram
9 % Originals from SMIME Free Library.
11 % Revision 1.1 1997/01/01 22:47:44 rj
15 \chapter{\label{modifying-chapter
}Modifying the Compiler
}
17 The compiler consists of about
30,
000 lines of yacc, lex and C code
18 (another
7,
000+ for the runtime library routines). The best way to
19 understand the compiler internals is to understand the module data
20 structure (
{\ufn \dots/compiler/core/asn1module.h
}) and to read the compiler
21 chapter in this
document to gain a conceptual understanding of each
24 The most common form of modification will likely be for macro
25 handling. To understand this, look at the way the OBJECT-TYPE macro is
28 \item[lex-asn1.l
] {add any new keywords
}
29 \item[parse-asn1.y
] { parse the macro into the desired data structure.
30 Use the existing productions as much as possible.
}
31 \item[link-type.c
] { link any type defined or referenced in the
33 \item[link-values.c
] { link any value defined or referenced in the
35 \item[do-macros.c
] { perform any semantic action for the macro
}
37 \item[normalize.c
] { move any type and value definitions in the macro
38 to the top level so the code generator can generate code for them
39 (without looking in the macro).
}
41 \item[code generators
] { to convert any special semantics into useful
42 C or C++. This phase is likely to be dependent on the generated
43 code's target environment.
}
46 In general I have tried to put comments where funky things happen and
47 to use function and variable names that are meaningful. However,
48 things may get ugly in certain places. Thesis writing is harmful to