[qcc] TCG

[Bruce Ewing]

> I don't want to _fork_ tcg.

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.

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.


On Fri, May 8, 2015 at 5:07 PM, Rob Landley <rob at landley.net> wrote:

> On 05/08/2015 04:33 PM, Bruce Ewing wrote:
> > I've been digging through the actual TCG code, and I've discovered the
> > following:
> >
> > The list of supported QEMU CPUs above are QEMU *frontends*, and are
> > mostly not available as TCG backends.
> >
> > TCG supports precisely eight backends: x86, ia64, mips, sparc, arm,
> > powerpc, s390, and aarch64. The aarch64 backend, however, is GPLv2
> > licensed -- so that one is out.
>
> Ouch.
>
> Early on (when tcg was first introduced) the code was symmetrical, if
> you had a frontend it had to also work s a backend.  Apparently they
> optimized that out in the past few years. :(
>
> Sadness.
>
> What I was really hoping was if we could get qemu developers interested
> in using this, they might fill in missing needed bits. (I don't want to
> _fork_ tcg. If anything it would be nice to contribute a working cc
> frontend upstream into the qemu repository, although this seems unlikely
> to fly. Secondly would be to make tcg a subrepo the way qemu has a
> couple existing subrepos it won't build without already...)
>
> > The TCG code itself is simply the backend from TCC, almost completely
> > unmodified (some sections deleted, and a few tiny features added to
> > support QEMU). Which means that all of the code that is missing to turn
> > it into a C compiler backend are already available in TCC.
> >
> > Which means that it should be completely brainless to attach it to QCC
> > as a backend -- where any other backend would require some thought. So
> > it looks like TCG does indeed win as the easiest backend.
>
> Yay!
>
> That's sort of what it looked like, but I never had time to do a proper
> deep dive into the code.
>
> Thanks,
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/qcc-landley.net/attachments/20150509/275be819/attachment-0002.htm>