X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=docs%2Fmini-porting.txt;h=e629aff8df7561521a97aaff691886575f060763;hb=a3ed5ef01f233106f82c7b3c709473f54f1dad49;hp=acca411cdbb9e68b72e1ec2dde5e5382c8f22d4e;hpb=a8b22e0e864c03b8cfd2f2cb5a8075b6611c5553;p=mono.git

diff --git a/docs/mini-porting.txt b/docs/mini-porting.txt
index acca411cdbb..e629aff8df7 100644
--- a/docs/mini-porting.txt
+++ b/docs/mini-porting.txt
@@ -415,6 +415,30 @@
 	*) 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
 
@@ -456,6 +480,52 @@
 	at this point, so the only parts which require changing are
 	the arch dependent files.
 
-
-
-	
+* Function descriptors
+
+	Some ABIs, like those for IA64 and PPC64, don't use direct
+	function pointers, but so called function descriptors.  A
+	function descriptor is a short data structure which contains
+	at least a pointer to the code of the function and a pointer
+	to a GOT/TOC, which needs to be loaded into a specific
+	register prior to jumping to the function.  Global variables
+	and large constants are accessed through that register.
+
+	Mono does not need function descriptors for the JITted code,
+	but we need to handle them when calling unmanaged code and we
+	need to create them when passing managed code to unmanaged
+	code.
+
+	mono_create_ftnptr() creates a function descriptor for a piece
+	of generated code within a specific domain.
+
+	mono_get_addr_from_ftnptr() returns the pointer to the native
+	code in a function descriptor.  Never use this function to
+	generate a jump to a function without loading the GOT/TOC
+	register unless the function descriptor was created by
+	mono_create_ftnptr().
+
+	See the sources for IA64 and PPC64 on when to create and when
+	to dereference function descriptors.  On PPC64 function
+	descriptors for various generated helper functions (in
+	exceptions-ppc.c and tramp-ppc.c) are generated in front of
+	the code they refer to (see ppc_create_pre_code_ftnptr()).  On
+	IA64 they are created separately.
+
+* Emulated opcodes
+
+	Mini has code for emulating quite a few opcodes, most notably
+	operations on longs, int/float conversions and atomic
+	operations.  If an architecture wishes such an opcode to be
+	emulated, mini produces icalls instead of those opcodes.  This
+	should only be considered when the operation cannot be
+	implemented efficiently and thus the overhead occured by the
+	icall is not relatively large.  Emulation of operations is
+	controlled by #defines in the arch header, but the naming is
+	not consistent.  They usually start with MONO_ARCH_EMULATE_,
+	MONO_ARCH_NO_EMULATE_ and MONO_ARCH_HAVE_.
+
+* Generic code sharing
+
+	Generic code sharing is optional.  See the file
+	"generic-sharing" for information on how to support it on an
+	architecture.