[Vm-dev] [GSoC] Report

Lars lars.wassermann at googlemail.com
Tue Aug 21 10:09:28 UTC 2012

Hello Mailinglist,
because this week, the GSoC program ends, here is a report on how far we 
are on the path of JITting on ARM.

A major step on that path is successfully simulating an image using the 
For that, we need emulation of ARM memory chunks on development systems 
and disassembling to support debugging.
Both things are done with Bochs for IA32, and ARMulator/libopcodes for 
ARM. Creating the GdbARMPlugin and testing it consumed the first half of 
the GSoC time. On that front, only smaller changes might be necessary.
For emulating, there might be a performance leak when simulating, 
because long jumps don't err when they jump, but only when they arrive, 
forgetting their origin. This requires the Simulator to be run in 
single-step mode, saving the last instruction, instead of just running.
For changing this, changing the main ARMulator loop might be necessary. 
And since we are not far enough, that performance is an issue, it is 
The disassembler works, but there seem to be different output 
conventions, e.g. ldmfd can also be translated as pop. Those different 
styles of disassembly are left to defaults, which might change depending 
on the build environment.

In the last weeks, we filled CogARMCompiler and CogGdbARMAlien.
The majority of abstract opcodes (from RTLOpcodes) is now implemented 
and can be used. Also, the ProcessorSimulationTrap errors are there. 
This allows the simulated code to request memory values and function 
values from the simulator. Some ProcessorSimulationTrap cases are not 
correct (they still have a halt), because they didn't occur, yet.
The AbstractCompilerTests are all green and we also added some more.

So what remains to be done?
While we can generate code and run it on the emulator, disassemble code 
chunks and even jump back into the simulator, the organisation of code 
is in parts very specific to IA32, because this was the primary and most 
important target.
For example in IA32, there exists a call opcode, while ARM has only 
branch and link. The Cogit expects the return address to be pushed, but 
ARM can not do that, without adding code to the preamble of each procedure.
The ARM ABI specifies that the arguments are first saved to registers r0 
through r3, before pushing additional arguments on the stack. But when 
calling back to the image, the translation so far generates code which 
pushes all the arguments, because this is IA32 ABI.
I would assume that there are plenty more of those smaller differences, 
which are hard coded in Cog, but need to be changed now, in order to 
enable ARM JITting.

And once the Simulator works, there is more glue code necessary. The 
only one I was confronted with so far is about flushing the ICache, but 
I expect there will be more.

Are there any questions?
See you next week in Gent,
Lars Wassermann

More information about the Vm-dev mailing list