doc/sparc/2

   1 .In
   2 .nr H1 1
   3 .NH
   4 CLOSE-UP LOOK
   5 .NH 2
   6 What is EM?
   7 .PP
   8 As the abstract of the IR-81 rapport on EM
   9 .[ [
  10 description of a machine architecture
  11 .]]
  12 says: \*(OQEM is a family
  13 of intermediate languages designed for producing portable compilers.\*(CQ
  14 Because EM is to be used on a wide range of languages and processors,
  15 the instruction set is kept simple enough to allow easy translation to,
  16 or interpretation on, almost any processor. Yet it is also powerful enough
  17 to accommodate easy translation from almost any block-structured language.
  18 .PP
  19 Even though EM was designed in the early 1980s, it
  20 is based on
  21 .\" already shows strong signs of being influenced by
  22 the (then innovative) RISC architecture. All instructions
  23 have 0 or 1 operands, there are no fancy addressing modes as in the
  24 68020's\*(Si move.w a3(_array,d3.w*2), -(sp)\*(So, no explicit registers,
  25 although instructions for higher languages
  26 such as array-operations, multiway branches (case) and
  27 floating point operations are provided.
  28 .PP
  29 To fully understand the discussion in the following chapters,
  30 the reader should at least have some knowledge of EM.
  31 .NH 2
  32 What is SPARC?
  33 .PP
  34 According to Sun's RISC tutorial: \*(OQSun Microsystems has designed a RISC
  35 architecture, called SPARC, and has implemented that architecture with
  36 the Sun-4 family of supercomputing workstations and servers. SPARC stands
  37 for Scalable Processor ARChitecture, emphasizing its applicability to
  38 large as well as small machines.\*(CQ
  39 .PP
  40 In sharp contrast to EM, SPARC does have
  41 explicit registers (31 integer and 32 floating point, all of which
  42 are 32 bits wide) and
  43 does not support any high level language operations: it does not even have
  44 multiplication or division instructions. Because the SPARC design is
  45 very straightforward, all instructions could be hard-coded (no microcode
  46 involved) to
  47 provided extremely high performance. All register-to-register operations
  48 require exactly one clock cycle, and all register-to-memory and
  49 memory-to-register operations require two clock cycles, one to retrieve
  50 the instruction and one to access external memory. At a clock speed of
  51 over 20 MHz this means that well over 10 VAX MIPS can be achieved:
  52 more than 4 times the speed of a 15 MHz 68020 used in the Sun3/50.
  53 .PP
  54 As above, the reader should also have some general knowledge about
  55 the SPARC processer to be able to understand the following chapters.
  56 .NH 2
  57 What exactly is a (fast) backend?
  58 .PP
  59 To put in the simplest of ways: a (fast) backend is a set of routines to
  60 translate EM code to code that will run 'on the metal' (for example the SPARC
  61 processor). The distinction between full-fledged backends (code generators)
  62 .[ [
  63 The table driven code generator
  64 .]]
  65 and fast backends (code expanders)
  66 .[ [
  67 The Code Expander Generator
  68 .]]
  69 is related to
  70 the compilation-time vs. run-time trade off. Code generators generate
  71 efficient code and code expanders generate code very efficient.
  72 For details about code expanders see also
  73 .[ [
  74 The design of very fast portable compilers
  75 .]].
  76 .PP
  77 The reasons for us to implement a code expander are numerous: Our first reason to
  78 implement a code expander, rather than a code generator was that implementing a
  79 code expander would be hard enough already. Code generators only give
  80 more problems and there were already enough problems to be solved. Secondly,
  81 we knew we would never be able to compete with original SPARC compilers due
  82 to loss of information in the frontends (see also chapter 5). By implementing
  83 a code expander we might be able to outrun the existing compilers on a
  84 completely different terrain: compile speed.
  85 .PP
  86 The third 'reason' to implement a code expander lies a little deeper and was
  87 not discovered until we had actually started the implementation... It was only
  88 then that we found out that for certain architectures, such as the SPARC,
  89 the idea behind the code-expander is not necessarily inferior to that
  90 behind a code-generator. It seems that for highly orthogonal instruction
  91 sets it is possible to generate near optimal code without using the
  92 code-expander. We have to say, however, that this is only true for our
  93 optimized version of the code-expander. With the original code-expander
  94 it would not have been possible to generate near-optimal code for the
  95 SPARC processor.
  96 .NH 2
  97 So, what are the main differences between EM and SPARC?
  98 .PP
  99 The main
 100 difference between EM and SPARC is the stack versus register orientation.
 101 The other differences, such as the presence of high level language
 102 operations in EM, can easily be overcome by subroutines,
 103 or small pieces of in-line SPARC code.
 104 The design-part of this project mostly concentrates on
 105 building a bridge between EM's stack and SPARC's registers.
 106 .PP
 107 In the next chapter we will make a list of all our design problems which
 108 will then be discussed in chapter 4.
 109 .bp