1               Notes on the Mips target (3/4/2012)
2               -----------------------------------
3
4Testing
5
6The initial implementation of Mips support in the compiler is untested on
7actual hardware, and as such should be expected to have many bugs.  However,
8the vast majority of code for Mips support is either shared with other
9tested targets, or was taken from the functional Mips JIT compiler.  The
10expectation is that when it is first tried out on actual hardware lots of
11small bugs will be flushed out, but it should not take long to get it
12solidly running.  The following areas are considered most likely to have
13problems that need to be addressed:
14
15    o Endianness.  Focus was on little-endian support, and if a big-endian
16      target is desired, you should pay particular attention to the
17      code generation for switch tables, fill array data, 64-bit
18      data handling and the register usage conventions.
19
20    o The memory model.  Verify that GenMemoryBarrier() generates the
21      appropriate flavor of sync.
22
23Register promotion
24
25The resource masks in the LIR structure are 64-bits wide, which is enough
26room to fully describe def/use info for Arm and x86 instructions.  However,
27the larger number of MIPS core and float registers render this too small.
28Currently, the workaround for this limitation is to avoid using floating
29point registers 16-31.  These are the callee-save registers, which therefore
30means that no floating point promotion is allowed.  Among the solution are:
31     o Expand the def/use mask (which, unfortunately, is a significant change)
32     o The Arm target uses 52 of the 64 bits, so we could support float
33       registers 16-27 without much effort.
34     o We could likely assign the 4 non-register bits (kDalvikReg, kLiteral,
35       kHeapRef & kMustNotAlias) to positions occuped by MIPS registers that
36       don't need def/use bits because they are never modified by code
37       subject to scheduling: r_K0, r_K1, r_SP, r_ZERO, r_S1 (rSELF).
38
39Branch delay slots
40
41Little to no attempt was made to fill branch delay slots.  Branch
42instructions in the encoding map are given a length of 8 bytes to include
43an implicit NOP.  It should not be too difficult to provide a slot-filling
44pass following successful assembly, but thought should be given to the
45design.  Branches are currently treated as scheduling barriers.  One
46simple solution would be to copy the instruction at branch targets to the
47slot and adjust the displacement.  However, given that code expansion is
48already a problem it would be preferable to use a more sophisticated
49scheduling solution.
50
51Code expansion
52
53Code expansion for the MIPS target is significantly higher than we see
54for Arm and x86.  It might make sense to replace the inline code generation
55for some of the more verbose Dalik byte codes with subroutine calls to
56shared helper functions.
57
58