[Qemu-devel] Perhaps a Virtual CPU for host?

[Qemu-devel] Perhaps a Virtual CPU for host?

[syeng]

I'm a lurker in this list and I'm not a developer, so please excuse me if
this isn't a good idea.

I've been wondering... Since Qemu is a binary translator, would it be
reasonable to have Qemu generate code for a virtual cpu instead of a real
cpu?

Then the program would run the virtual cpu emulator, which runs the code
generated by qemu.

In other words... No more back-ends for PPC, x86, Sparc, etc. etc.  Porting
to a new system would be easier, too.

Now, I know it sounds pretty bad.

BUT, I was thinking that if you chose the right virtual cpu architecture,
you might actually be able to get pretty decent performance out it.  I've
heard of cases where virtual cpu's ran benchmarks pretty well because each
instruction was easily decoded and each instruction did a lot of 'work'
(CISC vs. RISC.  For a virtual cpu, CISC style cpu's are better, I guess.)

I don't know how efficient the code is that Qemu generates, but it certainly
wouldn't be extremely efficient.  Perhaps a carefully chosen virtual cpu
architecture might make up for some of that, and perhaps run as fast as half
the speed of a native Qemu port?

If nothing else, it might provide a generic base for currently unsupported
host systems.

Any comments?

Re: [Qemu-devel] Perhaps a Virtual CPU for host?

[Jim C. Brown]

On Sat, Jul 17, 2004 at 08:42:13PM -0500, syeng wrote:
> I'm a lurker in this list and I'm not a developer, so please excuse me if
> this isn't a good idea.
> 
> I've been wondering... Since Qemu is a binary translator, would it be
> reasonable to have Qemu generate code for a virtual cpu instead of a real
> cpu?
> 
> Then the program would run the virtual cpu emulator, which runs the code
> generated by qemu.
> 
> In other words... No more back-ends for PPC, x86, Sparc, etc. etc.  Porting
> to a new system would be easier, too.
> 
> Now, I know it sounds pretty bad.
> 
> BUT, I was thinking that if you chose the right virtual cpu architecture,
> you might actually be able to get pretty decent performance out it.  I've
> heard of cases where virtual cpu's ran benchmarks pretty well because each
> instruction was easily decoded and each instruction did a lot of 'work'
> (CISC vs. RISC.  For a virtual cpu, CISC style cpu's are better, I guess.)
> 
> I don't know how efficient the code is that Qemu generates, but it certainly
> wouldn't be extremely efficient.  Perhaps a carefully chosen virtual cpu
> architecture might make up for some of that, and perhaps run as fast as half
> the speed of a native Qemu port?
> 
> If nothing else, it might provide a generic base for currently unsupported
> host systems.
> 
> Any comments?
> 

It should be fairly simple to modify the current qemu-system-i386 code and
make a qemu-system-a386 version. The a386 (http://a386.nocrew.org/) is a virtual
abstraction of the traditional i386 instruction set implemented in C, but it is
slightly cleaner.

a386 hasn't been updated in a while but its open source, so if you are really
interested this is a good place to start.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.