[Mono-list] PowerPC JIT

[Paolo Molaro]

On 08/26/02 Carlos Valiente wrote:
> * Created PPC equivalents of those x86-specific files under
> mono/arch/ppc. For now the only functional one is 'trampoline.c', which
> implements PowerPC JIT trampolines.
> 
> * Included mono/arch/ppc/test-trampoline.c, a small test program which
> checks whether trampoline code works or no (it does, right now :-))
> 
> I plan to carry on porting stuff from mono/arch/x86/emit-x86.c and
> creating a .brg file for PowerPC. Then I would hack on exception
> handling support and finally linear scan reg allocation. Any suggestions
> on this road plan?

regset.c and linear-scan.c (and their header files) should definitely
not be arch-specific. If currently there's some arch-specific code in
them, it should be removed (maybe changing them so that arch-specific
code can add hooks if needed, but that's all).
I suggest leaving exception handling support as the last thing to look
at in the port.
You should try the following, IMHO:
*) in metatada/appdomain.h:mono_runtime_init() remove the calls to
mono_thread_init() and mono_network_init(): they require quite a bit of
support from the jit that you don't have yet.
*) create a few simple test cases with a simple Main method like these:
	static void Main() {}
	static int Main() {return 1;}
	static int Main(string[] args) {return args.Length;}
	static int Main(string[] args) {return args.Length + 1;}
and so on, increasing the complexity (at the rate you're most confident
with). Make sure you can execute all of them.
mono/tests/* has a few simple cases as well (take fib.cs for example and
remove the useless Writelines). Use only integer test cases at first.
As you increase the complexity, you'll have to implement more rules in
the ppc.brg file, try to test each one and execute the tests (and
inspect the generated assembly). Use at first only int types, then start
adding short, byte and long and introduce conversions between them to
stress test as many opcodes as possible. You can probably ignore the
.ovf cases at this time and implement them simply as the non-ovf ones.
*) once you're confident with integer operations you can start tackle
the FP ops. This may be hard since the current JIT assumes a FP stack
as found on x86 cpus, but you should be able to use the register
allocation code that is already used for integers. Write a few simple
tests for FP operation this time and try to execise the reg allocator.
*) Introduce method calls, first static ones, then instance methods,
virtual calls and exercise the trampolines. Check registers are saved
correctly across calls.
*) Re-enable the appdomain.c code and start executing some real
programs (that don't use exceptions).
*) implement exception handling and stress-test it.
*) try to bootstrap mcs, corlib etc...:-)

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better