Difference between revisions of "Specializer"
m (fix links to spill & fill) | m (fix link for instruction slot) | ||
| Line 3: | Line 3: | ||
The specializer accepts a representation of the program targeted to the [[genAsm (code representation)|abstract]] Mill operation set, typically produced by a compiler. The representation has no knowledge of which [[Mill family member]] will be the execution target. The specializer transforms the abstract representation into a [[conAsm (code representation)|concrete ]] representation which reflects the capabilities of a particular target member. | The specializer accepts a representation of the program targeted to the [[genAsm (code representation)|abstract]] Mill operation set, typically produced by a compiler. The representation has no knowledge of which [[Mill family member]] will be the execution target. The specializer transforms the abstract representation into a [[conAsm (code representation)|concrete ]] representation which reflects the capabilities of a particular target member. | ||
| − | In operation, the specializer first substitutes emulation code for any abstract operations that are not present in native hardware on the target. It then places the program operations into instructions, ordered such that produced results are available when needed by consuming operations. The placing is constrained because each [[instruction slot]] is only able to execute a subset of the operation set. Lastly, the specializer determines the [[belt position]] numbers that let consuming operations reference their arguments. If necessary (due to the limited size of the belt), the specializer will introduce [[Instruction_Set/spill|spill]] and [[Instruction_Set/fill|fill]] operations to temporarily save operands to the [[scratchpad]]. | + | In operation, the specializer first substitutes emulation code for any abstract operations that are not present in native hardware on the target. It then places the program operations into instructions, ordered such that produced results are available when needed by consuming operations. The placing is constrained because each [[slot|instruction slot]] is only able to execute a subset of the operation set. Lastly, the specializer determines the [[belt position]] numbers that let consuming operations reference their arguments. If necessary (due to the limited size of the belt), the specializer will introduce [[Instruction_Set/spill|spill]] and [[Instruction_Set/fill|fill]] operations to temporarily save operands to the [[scratchpad]]. |
The specialized code is cached in the ELF code files or load modules, where it can be found by subsequent linking or loading steps. | The specialized code is cached in the ELF code files or load modules, where it can be found by subsequent linking or loading steps. | ||
Revision as of 21:28, 9 June 2015
The specializer is a component of the tool chain that translates programs in a high-level language to an executable binary encoding that can be executed on a Mill processor.
The specializer accepts a representation of the program targeted to the abstract Mill operation set, typically produced by a compiler. The representation has no knowledge of which Mill family member will be the execution target. The specializer transforms the abstract representation into a concrete representation which reflects the capabilities of a particular target member.
In operation, the specializer first substitutes emulation code for any abstract operations that are not present in native hardware on the target. It then places the program operations into instructions, ordered such that produced results are available when needed by consuming operations. The placing is constrained because each instruction slot is only able to execute a subset of the operation set. Lastly, the specializer determines the belt position numbers that let consuming operations reference their arguments. If necessary (due to the limited size of the belt), the specializer will introduce spill and fill operations to temporarily save operands to the scratchpad.
The specialized code is cached in the ELF code files or load modules, where it can be found by subsequent linking or loading steps.
