diff options
Diffstat (limited to 'doc/porting')
| -rw-r--r-- | doc/porting | 63 |
1 files changed, 0 insertions, 63 deletions
diff --git a/doc/porting b/doc/porting deleted file mode 100644 index a09ab69deaa..00000000000 --- a/doc/porting +++ /dev/null @@ -1,63 +0,0 @@ -* How to port Mono to your preferred architecture - -** Endian, 64 bits and unaligned access issues - - The first thing to do is to check that the metadata handling - library works on your target processor. You may use the disassembler - on simple programs and check that you get sensible results - (assuming it compiles at all on your system:-). - - The main issue is to write macros that read unaligned - little endian shorts/ints/longs/float/doubles: look into - mono/metadata/endian.h. There may be other spots in the code that are - unsafe at reading/writing to some datatypes that require special - alignment, but there should be few such issues and they need to be fixed. - - Once this stuff is sorted out, you should be able to run the interpreter - on simple programs that don't require delegates, P/Invoke functions etc.. - -** Generating assembly bytecodes for the target processor - - Next, you need to provide the support code for generating assembly bytecode - for your target platform (in mono/arch/{ppc,sparc,alpha,*}). - The code should be more or less like the code in x86-codegen.h: - macros that produce fast in-line code. You don't need to provide - code to create every possible code, at first, just the code to - create trampolines and execute them is fine (you'll need to research - how the call convention works on your platform): that would be, for - example, the prolog and epilog code in a function, code to pass function - parameters and deal with the return value and so on. - - libffi in gcc or the xptcall sources in mozilla may be helpful to - understand how the calling convention works, if you can't find a specification. - You'd need a processor manual to know how to create the assembly binary data. - This requires a lot of reading if you're not familiar with the assembly for your - target platform. Manuals for many processors are available as PDF files on the - web site of the respective vendors. Note that some processors require you to - flush the I-cache before executing the code: have a look at how the same thing is - done in GNU lightning. - -** Getting the interpreter to work - - Once you can generate binary code, you can start working on a - mono_create_trampoline() function for your platform: this function will receive - a MonoMethod that describes the arguments and the return type of a C function - and will create the code to call such function. When this function is complete - you'll be able to run more sample programs, that use System.IO, P/Invoke - functions etc. - - To support delegates you'll need to write a mono_create_method_pointer() - function that creates a native function: this can be used to call the - method using the runtime's calling convention (it's basically the reverse - of mono_create_trampoline()). - -** The final step: porting the JIT - - At this point you'd need to have a more complete code generation header file - and you can start writing the machine description file for the monoburg - system. This code (jit/tesjit.c) will require some machine specific tweaks, - but hopefully all you have to do is create the grammar that emit assembly - code from the IR tree. Work is at the early stages also for x86 on this stuff - as we are still testing various solutions: you'd want to read about burg-like - code-generator generators (the LCC book is a good starting point). - |