doc/sparc/3

   1 .In
   2 .nr H1 2
   3 .NH
   4 PROBLEMS
   5 .NH 2
   6 Maintain SPARC speed
   7 .PP
   8 If we want to generate SPARC code, we should try to generate efficient code
   9 as fast as possible. It would be quite embarrassing to find out that the
  10 same program would run faster on a Motorola 68020 than on a SPARC processor,
  11 when both operate at the same clock frequency.
  12 Looking at some code generated by Sun's C-compiler and optimizing assembler,
  13 we can spot a few remarkable characteristics of the generated SPARC code:
  14 .IP -
  15 There are almost no memory references
  16 .IP -
  17 Parameters to functions are passed through registers.
  18 .IP -
  19 Almost all delay slots\(dg
  20 .FS
  21 \(dg For details about delay slots see the SPARC Architecture Manual, chapter 4, pp. 42-48
  22 .FE
  23 are filled in by the assembler
  24 .LP
  25 If we want to generate efficient code, we should at least try to
  26 reduce the number of memory references and use registers wherever we can.
  27 Since EM is stack-oriented it references its stack for every operation so
  28 this will not be an easy task; a suitable solution will however be given in
  29 the next chapter.
  30 .NH 2
  31 Increase compilation speed
  32 .PP
  33 Because we will implement a code expander (fast backend) we should keep
  34 a close eye on efficiency; if we cannot beat regular compilers on producing
  35 efficient code we will try to beat them on fast code generation.
  36 The usual trick to achieve fast compilation is to pack the frontend,
  37 optimizer, code-generator and
  38 assembler all into a single large binary to reduce the overhead of
  39 reading and writing temporary files. Unfortunately, due to the
  40 SPARC instruction set, its relocation information is slightly bizarre
  41 and cannot be represented with the present primitives.
  42 This means that it will not be possible to generate the required output
  43 format directly from our backend.
  44 .PP
  45 There are three solutions here: generate assembler code, and let an
  46 existing assembler generate the required object (\fI.o\fR) files,
  47 create our own primitives than can handle the SPARC relocation format, or
  48 do not use any of the addressing modes that require the bizarre relocation.
  49 Because we have enough on our hands already we will
  50 let the existing assembler deal with generating object files.
  51 .NH 2
  52 Convert stack to register operations
  53 .PP
  54 As we wrote in the previous chapter, for RISC machines a code expander can
  55 produce almost as efficient code as a code generator. The fact that this is
  56 true for stack-oriented RISC processors is rather obvious. The problem we
  57 face, however, is that the SPARC processor is register, instead of
  58 stack oriented. In the next chapter we will give a suitable solution to
  59 convert most stack accesses to register accesses.
  60 .NH 2
  61 Miscellaneous
  62 .PP
  63 Besides performance and \fI.o\fR-compatibility there are some other
  64 peculiarities of the SPARC processor and Sun's C-compiler (henceforth
  65 simply called \fIcc\fR).
  66 .PP
  67 For some reason, the SPARC stack pointer requires alignment
  68 on 8 bytes, so it is impossible to push a 4-byte integer on the stack
  69 and then \*(Sisub 4, %sp\*(So\(dd.
  70 .FS
  71 \(dd For more information about SPARC assembler see the Sun-4 Assembly
  72 Language Reference Manual
  73 .FE
  74 This too will be discussed in the next chapter, where we will take a
  75 more in-depth look into this problem and also discuss a couple of
  76 possible solutions.
  77 .PP
  78 Another thing is that \fIcc\fR usually passes the first six parameters of a
  79 function-call through registers. To be \fI.o\fR-compatible we would have to
  80 pass the first six parameters of each function call through registers as well.
  81 Exactly why this is not feasible will also be discussed in the next chapter.
  82 .bp