Mupen64plus dynamic recompiler - Revision history

ABC: /* MIPS */ cat

2011-04-19T15:05:17Z

‎MIPS: cat

Ari64: Cache is 32MB by default in 20110128

2011-02-09T01:19:41Z

Cache is 32MB by default in 20110128

Ari64: /* Long jumps */

2011-02-02T21:58:46Z

‎Long jumps

Ari64: /* Constant propagation and register assignment */

2011-02-02T21:53:39Z

‎Constant propagation and register assignment

Ari64: /* Compile options */

2011-02-02T21:50:39Z

‎Compile options

Ari64: /* Self-modifying code detection */

2010-12-18T02:54:01Z

‎Self-modifying code detection

Esn: wikilink

2010-11-29T07:01:58Z

wikilink

Ari64: Interrupt handler

2010-11-29T05:36:32Z

Interrupt handler

Ari64: Debugging

2010-11-10T13:13:51Z

Debugging

Ari64: Potential improvements aren't necessarily future improvements, just possible ones

2010-10-11T04:32:18Z

Potential improvements aren't necessarily future improvements, just possible ones

← Older revision		Revision as of 15:05, 19 April 2011
Line 409:		Line 409:
	Recompiling MIPS into MIPS would be relatively straightforward, however the current code generator has no facility for filling delay slots. This capability would be required for efficient code generation.		Recompiling MIPS into MIPS would be relatively straightforward, however the current code generator has no facility for filling delay slots. This capability would be required for efficient code generation.

		+	[[Category:Emulators]]
		+	[[Category:Optimization]]
	[[Category:Development]]		[[Category:Development]]

@@ Line 68: / Line 68: @@
 ==A new approach==
-To reduce memory usage, the new design allocates a single large block of memory (currently 16 MiB) which is used for recompiled code.  This memory is allocated using mmap with the PROT_EXEC bit set, to ensure operation on CPUs with no-execute (NX) page permissions.
+To reduce memory usage, the new design allocates a single large block of memory (generally 32 MiB, but the size is configurable) which is used for recompiled code.  This memory is allocated using mmap with the PROT_EXEC bit set, to ensure operation on CPUs with no-execute (NX) page permissions.
 Contiguous blocks of MIPS instructions are compiled (that is, it does not attempt to follow branches or 'hot-paths').
@@ Line 136: / Line 136: @@
 The last step in new_recompile_block is to ensure that there will be sufficient memory available to compile the next block.  If there is not, then the oldest blocks are purged.
-The dynarec cache can be described as a 16MB circular buffer divided into eight segments.  Memory is allocated in order from beginning to end.
+The dynarec cache can be described as a 32MB circular buffer divided into eight segments.  Memory is allocated in order from beginning to end.
 When there are less than 2 empty segments, the next segment in sequence is cleared, wrapping around to the beginning of the buffer.  This continues as memory is needed, wrapping around from end to beginning.

← Older revision		Revision as of 21:58, 2 February 2011
Line 283:		Line 283:

	In TLB mode, the invalid_code array is not checked directly. Instead, pages are marked non-writable in memory_map.		In TLB mode, the invalid_code array is not checked directly. Instead, pages are marked non-writable in memory_map.
		+
		+	== Long jumps ==
		+
		+	Branch instructions are limited to a +/-32MB range on ARM. In some cases, the dynamic recompiler needs to generate calls to locations beyond this range. This is accomplished via a jump table located at the end of the code generation area, and the full address is loaded via a pointer. The jump table is generated in arch_init().
		+
		+	As these indirect jumps cause some delay, it is best to avoid this situation if possible, by locating this area close to the other executable code.

	== Compile options ==		== Compile options ==

← Older revision		Revision as of 21:53, 2 February 2011
Line 368:		Line 368:

	It would be helpful to recognize this as a load from r8+12345678. The current constant propagation code does not do so.		It would be helpful to recognize this as a load from r8+12345678. The current constant propagation code does not do so.
		+
		+	===Constant propagation and register assignment===
		+
		+	Constant propagation is currently done after register assignment. Registers are assigned even if the register will always contain a known value. In certain cases, such as where the constant is used only to generate a memory address, this could be avoided and no register would need to be allocated.

	===Unaligned memory access===		===Unaligned memory access===

← Older revision		Revision as of 21:50, 2 February 2011
Line 289:		Line 289:

	If this is defined, the UXTH instruction is not used, and the dynamic recompiler will generate literal pools instead of using movw/movt. This provides compatibility with older processors, but generates somewhat less efficient code.		If this is defined, the UXTH instruction is not used, and the dynamic recompiler will generate literal pools instead of using movw/movt. This provides compatibility with older processors, but generates somewhat less efficient code.
		+
		+	=== RAM_OFFSET ===
		+
		+	When compiling for ARM, this allocates an additional register which is used to add an offset to all pointers to memory addresses between 0x80000000 and 0x807FFFFF. This allows the N64's memory to be mapped at an alternate address. This incurs a small performance penalty, but is required for certain operating systems (eg Google Android, which places shared libraries at 0x80000000).
		+
		+	This option is not used for x86. The x86 instruction set allows for a full 32-bit offset in the instruction encoding, making it unnecessary to allocate an additional register for this purpose.

	=== CORTEX_A8_BRANCH_PREDICTION_HACK ===		=== CORTEX_A8_BRANCH_PREDICTION_HACK ===

← Older revision		Revision as of 02:54, 18 December 2010
Line 263:		Line 263:

	There is a special case of this, where a branch and delay slot span two pages. If a branch instruction is the last instruction in a virtual memory page, it is compiled in a different manner than other branches. The branch condition is evaluated, and the target address is placed in a register (%ebp on x86, and r8 on ARM). A special form of the dynamic linker (dyna_linker_ds) is used to link the branch to its corresponding delay slot in another block. If no page fault occurs, the delay slot executes and then jumps to the address in the register. For conditional branches that are not taken, the target address is the next instruction. This code is generated by the pagespan_assemble function.		There is a special case of this, where a branch and delay slot span two pages. If a branch instruction is the last instruction in a virtual memory page, it is compiled in a different manner than other branches. The branch condition is evaluated, and the target address is placed in a register (%ebp on x86, and r8 on ARM). A special form of the dynamic linker (dyna_linker_ds) is used to link the branch to its corresponding delay slot in another block. If no page fault occurs, the delay slot executes and then jumps to the address in the register. For conditional branches that are not taken, the target address is the next instruction. This code is generated by the pagespan_assemble function.
		+
		+	== Self-modifying code detection ==
		+
		+	Pages not containing code which has been compiled or where the code may have been modified since compilation are marked in the invalid_code array. Writes are checked against this array, and if a write hits a valid (compiled and unmodified) page, invalidate_block is called:
		+
		+	MIPS instruction: SW r1,8(r2)
		+
		+	ARM code:
		+	<source lang="text">
		+	ldr r3, [r11, #88] // pointer to invalid_code
		+	add r4, r2, #8
		+	cmp r4, #8388608
		+	bvc handler
		+	str r1, [r4]
		+	ldrb r14, [r3, r4 lsr #12]
		+	cmp r14, #1
		+	bne invstub
		+	</source>
		+
		+	In TLB mode, the invalid_code array is not checked directly. Instead, pages are marked non-writable in memory_map.

	== Compile options ==		== Compile options ==

← Older revision		Revision as of 07:01, 29 November 2010
Line 1:		Line 1:
−	This page describes the dynamic recompiler in ~~Mupen64plus~~, and the changes made for the ARM port.	+	This page describes the dynamic recompiler in [[Mupen64Plus]], and the changes made for the ARM port.

	==The original dynamic recompiler by Hacktarux==		==The original dynamic recompiler by Hacktarux==

← Older revision		Revision as of 05:36, 29 November 2010
Line 184:		Line 184:

	As in the original mupen64plus, the emulated clock runs at 37.5 MHz, and each instruction takes 2 clock cycles.		As in the original mupen64plus, the emulated clock runs at 37.5 MHz, and each instruction takes 2 clock cycles.
		+
		+	==Interrupt handler==
		+
		+	When the cycle count register reaches its limit, cc_interrupt is called, which in turn calls gen_interupt [sic]. If interrupts are not enabled, cc_interrupt returns. If interrupts are enabled, and an interrupt is to be taken, the pending_exception flag will be set. In this case, cc_interrupt does not return, and instead pops the stack and causes an unconditional jump to the address in pcaddr (usually 0x80000180).
		+
		+	There is one additional case where the interrupt handler may be called. If interrupts were disabled, and are enabled by writing to coprocessor 0 register 12, any pending interrupts are handled immediately.

	==Delay slots==		==Delay slots==

← Older revision		Revision as of 13:13, 10 November 2010
Line 283:		Line 283:

	Assume that the stack pointer (r29) is always a valid memory address and do not check it. It is similar to the optimization described [http://strmnnrmn.blogspot.com/2007/08/interesting-dynarec-hack.html here]. This can crash the emulator and is not enabled by default.		Assume that the stack pointer (r29) is always a valid memory address and do not check it. It is similar to the optimization described [http://strmnnrmn.blogspot.com/2007/08/interesting-dynarec-hack.html here]. This can crash the emulator and is not enabled by default.
		+
		+	== Debugging ==
		+
		+	Debugging information can be obtained by defining the assem_debug macro as printf. This will cause the dynamic recompiler to print debugging information to stdout. For each disassembled MIPS instruction, an entry similar to the following will be printed:
		+
		+	<source lang="text">
		+	U: r1 r8 r11 r16 r31 UU: r29 32: r0 r9
		+	pre: eax=-1 ecx=9 edx=-1 ebx=-1 ebp=29 esi=36 edi=-1
		+	needs: ecx ebp esi r: r9
		+	entry: eax=-1 ecx=9 edx=-1 ebx=-1 ebp=29 esi=36 edi=-1
		+	dirty: ecx ebp esi
		+	800001d8: LW r16,r29+14
		+	eax=16 ecx=9 edx=-1 ebx=-1 ebp=29 esi=36 edi=-1 dirty: eax ecx ebp esi
		+	32: r0 r9 r16
		+	</source>
		+
		+	U: A list of MIPS registers which will not be used before they are overwritten (liveness analysis)
		+
		+	UU: A list of MIPS registers for which the upper 32 bits will not be used before they are overwritten
		+
		+	32: Registers that contain 32-bit sign-extended values
		+
		+	pre: The state of the register mapping prior to execution of this instruction. (-1 = no mapping; 36 = cycle count; The complete list of values with special meanings can be found in the source code)
		+
		+	needs: a list of register mappings that were considered necessary and which could not be eliminated to make room for other mappings
		+
		+	r: Registers that are known to contain 32-bit values and where optimizations rely on the assumption that the register does not contain a value outside of the range -2<sup>31</sup> to 2<sup>31</sup>-1
		+
		+	entry: The minimum set of register mappings required to jump to this point
		+
		+	dirty: Cached registers that have been modified and will need to be written back
		+
		+	address: instruction - The decoded opcode, followed by the register mapping in effect after this instruction executes
		+
		+	An asterisk (*) designates locations which are the target of a branch instruction. Constant propagation will not be performed across these points.
		+
		+	After the complete disassembly, the recompiled native code is shown.
		+
		+	Note that the output can be quite voluminous; 20-30 MB is typical.

	==Potential improvements==		==Potential improvements==

@@ Line 284: / Line 284: @@
 Assume that the stack pointer (r29) is always a valid memory address and do not check it.  It is similar to the optimization described [http://strmnnrmn.blogspot.com/2007/08/interesting-dynarec-hack.html here].  This can crash the emulator and is not enabled by default.
-==Future improvements==
+==Potential improvements==
 ===Copy propagation/offset propagation===