porting 3.2 KB

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