+
+<p>TableGen permits the definition of parameterized classes as well as normal
+concrete classes. Parameterized TableGen classes specify a list of variable
+bindings (which may optionally have defaults) that are bound when used. Here is
+a simple example:</p>
+
+<div class="doc_code">
+<pre>
+<b>class</b> FPFormat<<b>bits</b><3> val> {
+ <b>bits</b><3> Value = val;
+}
+<b>def</b> NotFP : FPFormat<0>;
+<b>def</b> ZeroArgFP : FPFormat<1>;
+<b>def</b> OneArgFP : FPFormat<2>;
+<b>def</b> OneArgFPRW : FPFormat<3>;
+<b>def</b> TwoArgFP : FPFormat<4>;
+<b>def</b> CompareFP : FPFormat<5>;
+<b>def</b> CondMovFP : FPFormat<6>;
+<b>def</b> SpecialFP : FPFormat<7>;
+</pre>
+</div>
+
+<p>In this case, template arguments are used as a space efficient way to specify
+a list of "enumeration values", each with a "<tt>Value</tt>" field set to the
+specified integer.</p>
+
+<p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
+useful in conjunction with template arguments. As an example:</p>
+
+<div class="doc_code">
+<pre>
+<b>class</b> ModRefVal<<b>bits</b><2> val> {
+ <b>bits</b><2> Value = val;
+}
+
+<b>def</b> None : ModRefVal<0>;
+<b>def</b> Mod : ModRefVal<1>;
+<b>def</b> Ref : ModRefVal<2>;
+<b>def</b> ModRef : ModRefVal<3>;
+
+<b>class</b> Value<ModRefVal MR> {
+ <i>// Decode some information into a more convenient format, while providing
+ // a nice interface to the user of the "Value" class.</i>
+ <b>bit</b> isMod = MR.Value{0};
+ <b>bit</b> isRef = MR.Value{1};
+
+ <i>// other stuff...</i>
+}
+
+<i>// Example uses</i>
+<b>def</b> bork : Value<Mod>;
+<b>def</b> zork : Value<Ref>;
+<b>def</b> hork : Value<ModRef>;
+</pre>
+</div>
+
+<p>This is obviously a contrived example, but it shows how template arguments
+can be used to decouple the interface provided to the user of the class from the
+actual internal data representation expected by the class. In this case,
+running <tt>tblgen</tt> on the example prints the following definitions:</p>
+
+<div class="doc_code">
+<pre>
+<b>def</b> bork { <i>// Value</i>
+ <b>bit</b> isMod = 1;
+ <b>bit</b> isRef = 0;
+}
+<b>def</b> hork { <i>// Value</i>
+ <b>bit</b> isMod = 1;
+ <b>bit</b> isRef = 1;
+}
+<b>def</b> zork { <i>// Value</i>
+ <b>bit</b> isMod = 0;
+ <b>bit</b> isRef = 1;
+}
+</pre>
+</div>
+
+<p> This shows that TableGen was able to dig into the argument and extract a
+piece of information that was requested by the designer of the "Value" class.
+For more realistic examples, please see existing users of TableGen, such as the
+X86 backend.</p>
+
+</div>
+
+<!-- -------------------------------------------------------------------------->
+<div class="doc_subsubsection">
+ <a name="multiclass">Multiclass definitions and instances</a>
+</div>
+
+<div class="doc_text">
+
+<p>
+While classes with template arguments are a good way to factor commonality
+between two instances of a definition, multiclasses allow a convenient notation
+for defining multiple definitions at once (instances of implicitly constructed
+classes). For example, consider an 3-address instruction set whose instructions
+come in two forms: "<tt>reg = reg op reg</tt>" and "<tt>reg = reg op imm</tt>"
+(e.g. SPARC). In this case, you'd like to specify in one place that this
+commonality exists, then in a separate place indicate what all the ops are.
+</p>
+
+<p>
+Here is an example TableGen fragment that shows this idea:
+</p>
+
+<div class="doc_code">
+<pre>
+<b>def</b> ops;
+<b>def</b> GPR;
+<b>def</b> Imm;
+<b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
+
+<b>multiclass</b> ri_inst<<b>int</b> opc, <b>string</b> asmstr> {
+ def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+ def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+}
+
+<i>// Instantiations of the ri_inst multiclass.</i>
+<b>defm</b> ADD : ri_inst<0b111, "add">;
+<b>defm</b> SUB : ri_inst<0b101, "sub">;
+<b>defm</b> MUL : ri_inst<0b100, "mul">;
+...
+</pre>