doc/handbook/x86.tex

   1 \section{X86 code generator}
   2
   3 Porting to the famous x86 platform was more effort than
   4 expected. CACAO was designed to run on RISC machines from ground up,
   5 so the code generation part hat to be adapted. The first approach was
   6 to replace the simple RISC macros with x86 code, but this turned out
   7 to be not successful. So new x86 code generation macros where
   8 written. To be backward compatible, mostly in respect of embedded
   9 systems, all generated code can be run on i386 systems.
  10
  11 Some smaller problems occured since the x86 port was the first 32 bit
  12 target platform, like segmentation faults due to heap
  13 corruption. Another problem was the access to the functions data
  14 segment. Since RISC platforms like ALPHA and MIPS have a procedure
  15 pointer register, for the x86 platform there had to be implemented a
  16 special handling for accesses to the data segment, like
  17 \texttt{PUTSTATIC} and \texttt{GETSTATIC} instructions. The solution
  18 is like the handling of \textit{jump references} or \textit{check cast
  19 references}, which also have to be code patched, when the code and
  20 data segment are relocated. This means, there has to be an extra
  21 \textit{immediate-to-register} move (\texttt{i386\_mov\_imm\_reg()})
  22 before every \texttt{PUT}/\texttt{GETSTATIC} instruction, which moves
  23 the start address of the procedure, and thus the start address of the
  24 data segment, in one of the temporary registers.
  25
  26 Register usage was another problem in porting the CACAO to x86. An x86
  27 processor has 8 genernal purpose registers (GPR), of which one is the
  28 \textit{stack pointer} (SP) and thus it can not be used for arithmetic
  29 instructions. From the remaining 7 registers, in \textit{worst-case
  30 instructions} like \texttt{CHECKCAST} or \texttt{INSTANCEOF}, we need
  31 to reserve 3 temporary registers. So we have 4 registers available.
  32
  33
  34 \subsection{Calling conventions}
  35
  36 Normal calling convention of the x86 processor is passing all function
  37 arguments on the stack. The store size depends on the data type (the
  38 following types reflect the JAVA data types):
  39
  40 \begin{itemize}
  41 \item \texttt{byte}, \texttt{char}, \texttt{short}, \texttt{int},
  42       \texttt{float}, \texttt{void} --- 4 bytes
  43 \item \texttt{long}, \texttt{double} --- 8 bytes
  44 \end{itemize}
  45
  46 We changed this convention in a way, that we are using always 8 bytes
  47 on the stack for each datatype. With this adaptation, it was possible
  48 to use the \textit{stack space allocation algorithm} without any
  49 changes. The drawback of this decision was, that we have to copy all
  50 arguments of a native function call into a new stack frame and we have
  51 a slightly bigger memory footprint.
  52
  53 But calling a native function always means a stack manipulation,
  54 because you have to put the \textit{JNI environment}, and for
  55 \texttt{static} functions the \textit{class pointer}, in front of the
  56 function parameters. So this negligible.
  57
  58 For some \texttt{BUILTIN} functions there had to be written
  59 \texttt{asm\_} counterparts, which copy the 8 byte parameters in their
  60 correct size in a new stack frame. But this only affected
  61 \texttt{BUILTIN} functions with more than 1 function parameter. To be
  62 exactly, 2 functions, namely \texttt{arrayinstanceof} and
  63 \texttt{newarray}. So this is not a big speed impact.
  64
  65
  66 \subsection{Register allocator}
  67
  68 As mentioned before, in  \textit{worst-case situations} there are only
  69 4 integer registers available. We use \texttt{\%ebp}, \texttt{\%esi},
  70 \texttt{\%edi} as callee saved registers (which are callee saved
  71 registers in the x86 ABI) and \texttt{\%ebx} as scratch register
  72 (which is also a callee saved register in the x86 ABI, but we need
  73 some scratch registers). So we have a lack of scratch registers. But
  74 for most ICMD instructions, we do not need all, or sometimes none, of
  75 the temporary registers.
  76
  77 This fact we use in the \texttt{analyse\_stack()} pass. We try to use
  78 \texttt{\%edx} (which is \texttt{REG\_ITMP3}) and \texttt{\%ecx} (which
  79 is \texttt{REG\_ITMP2}) as scratch registers for the register allocator
  80 if certain ICMD instructions are not used in the compiled method.
  81
  82 So, for \textit{best-case situations} CACAO has 3 \textit{callee
  83 saved} and 3 \textit{scratch} registers.
  84
  85 This analysis should be changed from \textit{method level} to
  86 \textit{basic-block level}, so CACAO could emit better code on x86.
  87
  88
  89 \subsection{Long arithmetic}
  90
  91 Unlike the PowerPC port, we cannot put \texttt{long}'s in 2 32 bit
  92 integer registers, since we have to little of them. Maybe this could
  93 bring a speedup, if the register allocator would be more intelligent
  94 or in leaf functions which have only \texttt{long} variables. But this
  95 is not implemented yet. So, the current approach is to store all
  96 \texttt{long}'s in memory, this means they are always spilled.
  97
  98 Nearly all \texttt{long} instructions are inline, except 2 of them:
  99 \texttt{LDIV} and \texttt{LREM}. These 2 are computed via
 100 \texttt{BUILTIN} calls.
 101
 102 All of the \texttt{long} instructions operate on 64 bit, even if it is
 103 not necessary. The dependency information that would be needed to just
 104 operate on the lower or upper half of the \texttt{long} variable, is
 105 not generated by CACAO.
 106
 107
 108 \subsection{Floating point arithmetic}
 109
 110 Since the i386, with it's i387 counterpart or the i486, the x86
 111 processor has an \textit{floating point unit} (FPU). This FPU is
 112 implemented as a stack with 8 elements.