<div dir="ltr"><div><br></div><div>> I don't want to _fork_ tcg.</div><div><br></div><div>It would be nicest if it could work out that way. However, the current tcg code uses GCC extensions. At the very least, I saw it use __func__ and arithmetic on void * values. So either QCC would have to be extended to handle those, or the QEMU guys would have to voluntarily remove it from TCG.</div><div><br></div><div>Beyond that, there is a possibility that the logic may simply require mods in the TCG code (to handle floating point, maybe?) -- and then comes the question of whether the QEMU guys would accept non-QEMU-based mods in their TCG.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 8, 2015 at 5:07 PM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/08/2015 04:33 PM, Bruce Ewing wrote:<br>
> I've been digging through the actual TCG code, and I've discovered the<br>
> following:<br>
><br>
> The list of supported QEMU CPUs above are QEMU *frontends*, and are<br>
> mostly not available as TCG backends.<br>
><br>
> TCG supports precisely eight backends: x86, ia64, mips, sparc, arm,<br>
> powerpc, s390, and aarch64. The aarch64 backend, however, is GPLv2<br>
> licensed -- so that one is out.<br>
<br>
</span>Ouch.<br>
<br>
Early on (when tcg was first introduced) the code was symmetrical, if<br>
you had a frontend it had to also work s a backend.  Apparently they<br>
optimized that out in the past few years. :(<br>
<br>
Sadness.<br>
<br>
What I was really hoping was if we could get qemu developers interested<br>
in using this, they might fill in missing needed bits. (I don't want to<br>
_fork_ tcg. If anything it would be nice to contribute a working cc<br>
frontend upstream into the qemu repository, although this seems unlikely<br>
to fly. Secondly would be to make tcg a subrepo the way qemu has a<br>
couple existing subrepos it won't build without already...)<br>
<span class=""><br>
> The TCG code itself is simply the backend from TCC, almost completely<br>
> unmodified (some sections deleted, and a few tiny features added to<br>
> support QEMU). Which means that all of the code that is missing to turn<br>
> it into a C compiler backend are already available in TCC.<br>
><br>
> Which means that it should be completely brainless to attach it to QCC<br>
> as a backend -- where any other backend would require some thought. So<br>
> it looks like TCG does indeed win as the easiest backend.<br>
<br>
</span>Yay!<br>
<br>
That's sort of what it looked like, but I never had time to do a proper<br>
deep dive into the code.<br>
<br>
Thanks,<br>
<br>
Rob<br>
</blockquote></div><br></div>