Paul Brook wrote:
I know I'd seen something like this before, thanks for reminding me.
There are several issues with PearColator/RVM:
- It's written in java. qemu is written in C, so a lot of porting would be
required to get anything working.
- The best benchmark results are half the speed of qemu, and ten times slower
appears to be a more typical result.
- I can't see an any way of doing an incremental transition. My code generator
coexists with dyngen, allowing a gentle migration away from dyngen.
The currently published benchmark results are for PearColator with just
an optimizing compiler (worst case in Jikes RVM is over 100 compiler
stages). We also emulate a TLB in much the same way as PearPC, so
comparing us to QEMU fast isn't fair (we generate in the region of 10
instructions for loads and stores whereas QEMU fast can generate 1). Our
best results are for things that sit in dynamic code for a long period
of time, which isn't too surprising. We are working on equivalent
results to QEMU fast, but our approach is different to that of QEMU and
I completely agree that trying to get QEMU/PearColator to co-exist
wouldn't be that great.
Regards,
Ian Rogers
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel