Compilers for Customisable Processors

The embedded computing word is characterised by a blend of stringent constraints such as high performance, low power, and fast time to market. In such scenario, Customisable Processors represent a very attracting solution, as they typically allow designers to extend relatively simple processors with application-specific features. Many of such processors have emerged in the market, e.g., Tensilica Xtensa, ARC ARCtangent, STMicroelectronics ST200, and Xilinx Virtex-4, all allowing some degree of extensibility. In particular, they provide the designer with the possibility of adding Instruction Set Extensions (ISEs) to a basic Instruction Set, so that critical parts of an embedded application can be run in hardware, in Application-specific Functional Units (AFUs). The figure below depicts a simplified view of a customisable processor extended with an AFU, aimed at executing a critical part of an application directly in hardware. 



Typical extensible processor with a five-input three-output application-specific functional unit.


Of course, an important design decision lays in which part of the application code is best assigned to ISEs. Most customisable processors in the market still leave to the designer the task of choosing the most efficient ISEs for a given application---while
providing development environments with simulation capabilities for evaluating the efficiency of hand-crafted ISEs. On the other hand, research teams have proposed in the last decade a number of methods for identifying such ISEs automatically, from application source code---see our page on automatic instruction set extension---and these methods are slowly but surely finding their place in commercial solutions.  Design Automation is therefore raising to the point that application-specific ISEs can be identified by a software module, analysing the application source code. Naturally, this software module can be seen as part of a (very particular) compiler.

Effectively, what we are witnessing is an automation trend that gives the compiler more and more capabilities, and this in turn leads to the observation that the compiler role is changing. Observe the next figure: Initially, the compiler simply translated a high-level source code into machine code for a given machine, as in part (a) of the figure. Part (b) shows the role of retargetable compilers that later emerged, and that are able to translate source code into machine code for a set of machines, by reading a machine description as input. However, we can now go one step further and introduce a compiler---shown in part (c)---that is itself allowed to complete the machine description, i.e. to define application-specific extensions to a basic Instruction Set, and then compile onto it.





a) A compiler for a specific machine. b) A retargetable compiler reads in a machine description and generates code for it. c) A compiler for a customisable processor can generate the description of the best machine for a given application, and then produce code for it.



The inspiration for this research comes precisely from the realisation of this new compiler role, and, in particular, a question begs to be answered: are traditional compiler techniques, aimed at standard RISC microprocessor execution, suitable for this new compilation process, i.e., compilation including the definition of Instruction Set Extensions? Or do traditional techniques need to be redesigned, or at least re-tuned, in order to be beneficial in this new scenario?  We argue that there is indeed a need to revisit many traditional compiler decisions. See: