1 * How to port Mono to your preferred architecture
3 ** Endian, 64 bits and unaligned access issues
5 The first thing to do is to check that the metadata handling
6 library works on your target processor. You may use the disassembler
7 on simple programs and check that you get sensible results
8 (assuming it compiles at all on your system:-).
10 The main issue is to write macros that read unaligned
11 little endian shorts/ints/longs/float/doubles: look into
12 mono/metadata/endian.h. There may be other spots in the code that are
13 unsafe at reading/writing to some datatypes that require special
14 alignment, but there should be few such issues and they need to be fixed.
16 Once this stuff is sorted out, you should be able to run the interpreter
17 on simple programs that don't require delegates, P/Invoke functions etc..
19 ** Generating assembly bytecodes for the target processor
21 Next, you need to provide the support code for generating assembly bytecode
22 for your target platform (in mono/arch/{ppc,sparc,alpha,*}).
23 The code should be more or less like the code in x86-codegen.h:
24 macros that produce fast in-line code. You don't need to provide
25 code to create every possible code, at first, just the code to
26 create trampolines and execute them is fine (you'll need to research
27 how the call convention works on your platform): that would be, for
28 example, the prolog and epilog code in a function, code to pass function
29 parameters and deal with the return value and so on.
31 libffi in gcc or the xptcall sources in mozilla may be helpful to
32 understand how the calling convention works, if you can't find a specification.
33 You'd need a processor manual to know how to create the assembly binary data.
34 This requires a lot of reading if you're not familiar with the assembly for your
35 target platform. Manuals for many processors are available as PDF files on the
36 web site of the respective vendors. Note that some processors require you to
37 flush the I-cache before executing the code: have a look at how the same thing is
38 done in GNU lightning.
40 ** Getting the interpreter to work
42 Once you can generate binary code, you can start working on a
43 mono_create_trampoline() function for your platform: this function will receive
44 a MonoMethod that describes the arguments and the return type of a C function
45 and will create the code to call such function. When this function is complete
46 you'll be able to run more sample programs, that use System.IO, P/Invoke
49 To support delegates you'll need to write a mono_create_method_pointer()
50 function that creates a native function: this can be used to call the
51 method using the runtime's calling convention (it's basically the reverse
52 of mono_create_trampoline()).
54 ** The final step: porting the JIT
56 At this point you'd need to have a more complete code generation header file
57 and you can start writing the machine description file for the monoburg
58 system. This code (jit/tesjit.c) will require some machine specific tweaks,
59 but hopefully all you have to do is create the grammar that emit assembly
60 code from the IR tree. Work is at the early stages also for x86 on this stuff
61 as we are still testing various solutions: you'd want to read about burg-like
62 code-generator generators (the LCC book is a good starting point).