An optimizing assembler for explicitly parallel instruction computing (EPIC) architectures

An optimizing assembler for EPIC processors is capable of generating code that is compact and customized to take advantage of the processor's internal parallel structure. While most programs today are written in high-level languages such as C++ or Java, a significant amount of code is still written in assembly language. The reasons for using assembly language vary with the application. For example, interrupt handlers in operating systems are often written in assembly, and high performance embedded application programs typically use special purpose instructions that high level compilers do not generate. Traditional assemblers handled the somewhat straightforward task of mapping assembly code directly to binary machine code. However, newly developed EPIC architectures, such as Intel's Itanium processor, offer assemblers the opportunity to generate and schedule instructions for parallel execution.; The specific issues addressed by this research include: the programming of EPIC processors from assembly source code, the design of assembler directives appropriate for EPIC architectures, and the development of a methodology that exposes maximum amount of code parallelism while conforming to programmer-directed code generation constraints. The latter issue is embodied in flexible region formation technique called the Embedded Super Block (ESB) for resource-constrained embedded systems. The concept of programming EPIC processors from assembly source code has manifested into a recently developed prototype optimizing EPIC assembler called the Serial Input Parallelizing Assembler (SPASM). The development of this prototype has revealed several substantial research issues whose treatment is likely to differ from that of related compiler research.; The evidence put forth in this dissertation proves that an optimizing assembler may perform code generation in a manner similar to that of an optimizing compiler while achieving as much as a 48% speedup performance improvement as compared to the performance characteristics of non-optimized version of the code. The amount of code growth required to achieve this performance was an average of only 4 percent over the non-optimized version of the source code.