.In .nr H1 1 .NH CLOSE-UP LOOK .NH 2 What is EM? .PP As the abstract of the IR-81 rapport on EM .[ [ description of a machine architecture .]] says: \*(OQEM is a family of intermediate languages designed for producing portable compilers.\*(CQ Because EM is to be used on a wide range of languages and processors, the instruction set is kept simple enough to allow easy translation to, or interpretation on, almost any processor. Yet it is also powerful enough to accommodate easy translation from almost any block-structured language. .PP Even though EM was designed in the early 1980s, it is based on .\" already shows strong signs of being influenced by the (then innovative) RISC architecture. All instructions have 0 or 1 operands, there are no fancy addressing modes as in the 68020's\*(Si move.w a3(_array,d3.w*2), -(sp)\*(So, no explicit registers, although instructions for higher languages such as array-operations, multiway branches (case) and floating point operations are provided. .PP To fully understand the discussion in the following chapters, the reader should at least have some knowledge of EM. .NH 2 What is SPARC? .PP According to Sun's RISC tutorial: \*(OQSun Microsystems has designed a RISC architecture, called SPARC, and has implemented that architecture with the Sun-4 family of supercomputing workstations and servers. SPARC stands for Scalable Processor ARChitecture, emphasizing its applicability to large as well as small machines.\*(CQ .PP In sharp contrast to EM, SPARC does have explicit registers (31 integer and 32 floating point, all of which are 32 bits wide) and does not support any high level language operations: it does not even have multiplication or division instructions. Because the SPARC design is very straightforward, all instructions could be hard-coded (no microcode involved) to provided extremely high performance. All register-to-register operations require exactly one clock cycle, and all register-to-memory and memory-to-register operations require two clock cycles, one to retrieve the instruction and one to access external memory. At a clock speed of over 20 MHz this means that well over 10 VAX MIPS can be achieved: more than 4 times the speed of a 15 MHz 68020 used in the Sun3/50. .PP As above, the reader should also have some general knowledge about the SPARC processer to be able to understand the following chapters. .NH 2 What exactly is a (fast) backend? .PP To put in the simplest of ways: a (fast) backend is a set of routines to translate EM code to code that will run 'on the metal' (for example the SPARC processor). The distinction between full-fledged backends (code generators) .[ [ The table driven code generator .]] and fast backends (code expanders) .[ [ The Code Expander Generator .]] is related to the compilation-time vs. run-time trade off. Code generators generate efficient code and code expanders generate code very efficient. For details about code expanders see also .[ [ The design of very fast portable compilers .]]. .PP The reasons for us to implement a code expander are numerous: Our first reason to implement a code expander, rather than a code generator was that implementing a code expander would be hard enough already. Code generators only give more problems and there were already enough problems to be solved. Secondly, we knew we would never be able to compete with original SPARC compilers due to loss of information in the frontends (see also chapter 5). By implementing a code expander we might be able to outrun the existing compilers on a completely different terrain: compile speed. .PP The third 'reason' to implement a code expander lies a little deeper and was not discovered until we had actually started the implementation... It was only then that we found out that for certain architectures, such as the SPARC, the idea behind the code-expander is not necessarily inferior to that behind a code-generator. It seems that for highly orthogonal instruction sets it is possible to generate near optimal code without using the code-expander. We have to say, however, that this is only true for our optimized version of the code-expander. With the original code-expander it would not have been possible to generate near-optimal code for the SPARC processor. .NH 2 So, what are the main differences between EM and SPARC? .PP The main difference between EM and SPARC is the stack versus register orientation. The other differences, such as the presence of high level language operations in EM, can easily be overcome by subroutines, or small pieces of in-line SPARC code. The design-part of this project mostly concentrates on building a bridge between EM's stack and SPARC's registers. .PP In the next chapter we will make a list of all our design problems which will then be discussed in chapter 4. .bp