[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu vs gcc4

From: K. Richard Pixley
Subject: Re: [Qemu-devel] qemu vs gcc4
Date: Mon, 23 Oct 2006 10:41:44 -0700
User-agent: Thunderbird (X11/20060921)

Martin Guy wrote:
Now, gcc4 can produce code with several return instructions (with no
option to turn that of, as far as I understand). You cannot cut them out,
and therefore you cannot chain the simple functions.

...unless you also map return instructions within the generated
functions into branches to the soon-to-be-dropped final "return"? Not
that I know anything about qemu internals mind u...
Seems to me one could also map them into jumps to a null function.

Although, all told, it would seem to me that what might be called for here is a new gcc target. A gcc target specifically for generating qemu code. That would just simply generate whatever qemu wanted for function postamble.

It would probably mean separating out the code intended to run as native code from the code intended to run on behalf of the emulated target, and it would mean that you'd need a "gcc-qemu" to build the latter, but it would solve the problem permanently. It could also then be done in a cpu independent fashion such that any gcc target port might be converted trivially into a gcc target-for-qemu port. This should also make the chaining task much simpler and since that would seem to need to be done at run time, this could easily be a performance enhancement as well.

I see two real downsides to this approach. The first is that qemu becomes wed to gcc. That seems to be a defacto requirement now, but using a custom gcc target would make that marriage pretty permanent. Creating qemu targets for other compilers would be near impossible, although if the code were properly separated, you could still use a non-gcc target for the intended-for-host instructions.

The second downside is that some of the qemu support stuff would no longer be in the qemu code distribution. Instead, it would be in gcc. This opens the possiblity for version slew problems and authority over maintenance issues in the long term. Administratively, it'd be an additional load.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]