doc/handbook/powerpc.tex

   1 \section{PowerPC code generator}
   2
   3 The PowerPC code generator was the first to target a 32~bit RISC processor.
   4 Being RISC, most of the code generation was easily done, working from the Alpha
   5 code generator as a starting point. Furthermore, the i386 port was well
   6 underway at that time, so everything was 32~bit clean already.
   7
   8 Unless mentioned otherwise, everything was eventually translated to PowerPC
   9 machine language almost literally. Especially, exception handling, the data
  10 segment layout, most of the arithmetic operations, glue functions for calling C
  11 from generated code and the other way round and functions for thread switching
  12 are essentially the same as on the earlier RISC ports.
  13
  14 The part of the JVM causing most troubles for the PowerPC port was of course
  15 the long data type. These 64~bit values had to be split into two 32~bit
  16 registers in a manner not to disrupt the working of the simple register
  17 allocator already in place. A very simplistic approach was chosen that permits
  18 only consecutive registers to be combined into one long value. Every integer
  19 register is allowed to pair with its successor. To ensure that an argument
  20 register is not paired with, say, a saved register, the registers available for
  21 pairing were divided into three separate groups of saved registers, temporary
  22 registers and argument registers respectively.
  23
  24 \subsection{Calling conventions}
  25
  26 The PowerPC calling conventions required some additional work. Some argument
  27 register allocation suitable for the Alpha and MIPS calling conventions is
  28 already done in the stack analysis stage. While the PowerPC scheme could have
  29 been fitted into the stack analyser as well, it was decided against doing so
  30 because the stack analysis is already quite complicated and verbose. Adding
  31 lots of conditionals to support the variety of specific code generators would
  32 not help making the code any clearer. Therefore, an extra pass was added just
  33 after the stack analysis that renumbers all the argument registers for use by
  34 the register allocator.
  35
  36 \subsection{Register allocator}
  37
  38 The register allocator also underwent some adaptions. Allocating register pairs
  39 for 64~bit values was not much of a problem. Argument register allocation for
  40 the PowerPC ABI was more difficult because different from Alpha and MIPS and
  41 was finally overcome with the introduction of the afforementioned additional
  42 renumbering pass.
  43
  44 Things would have been simpler by using the same calling conventions as on
  45 Alpha -- after all, the code generator can dictate its own conventions.
  46 However, generated code can also call C~functions via the BUILTIN instruction,
  47 so the PowerPC~ABI conventions had to be implemented anyway. The PowerPC~ABI
  48 also requires a somewhat different stack layout than the one used on Alpha.
  49 Each calling function must reserve a linkage area for use by the callee where
  50 all used argument registers can be saved. This linkage area is not used by
  51 generated code, so a distinction could have been made between calls to C~code
  52 and calls to Java~code in order to save some stack space. Although the register
  53 allocator is simple, it is spread out all over the JIT modules and very easy to
  54 mess up. Thus it was decided against that distinction at the expense of some
  55 wasted stack space.
  56
  57 \subsection{Long arithmetic}
  58
  59 All bitwise 64~bit operations require the same operation to be carried out
  60 twice, on each half of the long data. Arithmetic operations like add, sub, neg
  61 are similar in this regard in that they don't consist of exactly the same
  62 operation executed twice but nevertheless two separate instructions. Presumably
  63 some of these operations could be saved by some kind of dependency analysis.
  64 However, no such analysis is in place in CACAO, so the simple approach was
  65 taken to always process both halves, even if one of them is just thrown away.