2008-11-20 Jb Evain <jbevain@novell.com>
[mono.git] / docs / mini-porting.txt
index 25be0a775665700e4144717a60be84635f938c60..cdb967d3d9e5fe5ee97df41286c8b0c6306a5d94 100644 (file)
        collecting liveness information and in a backward pass on the
        same list performs the actual register allocation, inserting
        the instructions needed to spill values, if necessary.
+
+       The cross-platform local register allocator is now implemented
+       and it is documented in the jit-regalloc file.
        
        When this part of code is implemented, some testing can be
        done with the generated code for the new architecture. Most
        tests.  Also, using multiple -v switches on the command line
        makes the JIT dump an increasing amount of information during
        compilation.
-       
+
+       Values loaded into registers need to be extened as needed by
+       the ECMA specs:
+
+       *) integers smaller than 4 bytes are extended to int32 values
+       *) 32 bit floats are extended to double precision (in particular
+       this means that currently all the floating point operations operate
+       on doubles)
        
 * Method trampolines
 
        *) mono_arch_instrument_epilog ()
                Functions needed to implement the profiling interface.
        
+* Testing the port
+
+    The JIT has a set of regression tests in *.cs files inside the mini directory.
+    The usual method of testing a port is by compiling these tests on another machine
+       with a working runtime by typing 'make rcheck', then copying TestDriver.dll and
+       *.exe to the mini directory. The tests can be run by typing:
+       ./mono --regression <exe file name>
+       The suggested order for working through these tests is the following:
+       - basic.exe
+       - basic-long.exe
+       - basic-float.exe
+       - basic-calls.exe
+       - objects.exe
+       - arrays.exe
+       - exceptions.exe
+       - iltests.exe
+       - generics.exe  
        
 * Writing regression tests
 
        we replace one or more instructions with others that perform
        better for the given architecture or CPU.
        
+* 64 bit support tips, by Zoltan Varga (vargaz@gmail.com)
+
+       For a 64-bit port of the Mono runtime, you will typically do
+       the following:
+
+               * need to use inssel-long.brg instead of
+                 inssel-long32.brg.
+
+               * need to implement lots of new opcodes:
+                      OP_I<OP> is 32 bit op
+                      OP_L<OP> and CEE_<OP> are 64 bit ops
+
+
+       The 64 bit version of an existing port might share the code
+       with the 32 bit port (for example SPARC/SPARV9), or it might
+       be separate (x86/AMD64).  
+
+       That will depend on the similarities of the two instructions
+       sets/ABIs etc.
+
+       The runtime and most parts of the JIT are 64 bit clean
+       at this point, so the only parts which require changing are
+       the arch dependent files.
+
+
+
+