[Vm-dev] [GSoC] Report
lars.wassermann at googlemail.com
Tue Aug 21 10:09:28 UTC 2012
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
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,
More information about the Vm-dev