Re: [Qemu-devel] qemu vs gcc4

["K. Richard Pixley" <rich.pixley@palmsource.com>]

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.

--rich