Announcement

Collapse
No announcement yet.

Pairing A C Compiler With QEMU's Code Generator

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pairing A C Compiler With QEMU's Code Generator

    Phoronix: Pairing A C Compiler With QEMU's Code Generator

    Earlier this week when writing about the state of the Tiny C Compiler, I learned more about QCC. QCC is a new initiative to pair a forked version of the Tiny C Compiler (TCC) with QEMU's code generator...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Landley tells me that QCC is going to be on the agenda once Aboriginal Linux switches from uclibc to musl (next release), and toybox (his BSD-licensed replacement for BusyBox, which you can extend by dropping in a single file for each applet you want to add) reaches 1.0.
    Toybox is at 0.4.x right now, so I'm guessing ~1-2 years more...
    QCC will be BSD-licensed; QCG is already, and he has gotten permission from Fabrice for using Fabrice's code in TCC under that license.
    Much of the work on tcc 0.9.24 was based on Landley's work (http://landley.net/code/tinycc/), but some of the most recent changes are ones he may need to redo/inquire about. Specifically, he mentioned variable length arrays as something that needed to happen for the kernel to build.
    As far as I can tell, tcc doesn't support weak symbols, so it doesn't work for compiling musl (what I was interested in).

    And in case you're wondering why anyone wants to compile the kernel with TCC:
    1-small codebase for a self-hosting environment
    2-avoid GNU (for bloat and because of the FSF's attempts to rewrite history)
    About the latter, here's Ulrich Drepper's comments from the glibc 2.2.4 release notes:
    The glibc situation is even more frightening if one realizes the story
    behind it. When I started porting glibc 1.09 to Linux (which
    eventually became glibc 2.0) Stallman threatened me and tried to force
    me to contribute rather to the work on the Hurd. Work on Linux would
    be counter-productive to the Free Software course. Then came, what
    would be called embrace-and-extend if performed by the Evil of the
    North-West, and his claim for everything which lead to Linux's
    success.


    Which brings us to the second point. One change the SC forced to
    happen against my will was to use LGPL 2.1 instead of LGPL 2. The
    argument was that the poor lawyers cannot see that LGPL 2 is
    sufficient. Guess who were the driving forces behind this.

    The most remarkable thing is that Stallman was all for this despite
    the clear motivation of commercialization. The reason: he finally got
    the provocative changes he made to the license through. In case you
    forgot or haven't heard, here's an excerpt:

    [...] For example, permission to use the GNU C Library in non-free
    programs enables many more people to use the whole GNU operating
    system, as well as its variant, the GNU/Linux operating system.

    This $&%$& demands everything to be labeled in a way which credits him
    and he does not stop before making completely wrong statements like
    "its variant". I find this completely unacceptable and can assure
    everybody that I consider none of the code I contributed to glibc
    (which is quite a lot) to be as part of the GNU project and so a major
    part of what Stallman claims credit for is simply going away.

    This part has a morale, too, and it is almost the same: don't trust
    this person. Read the licenses carefully and rip out parts which give
    Stallman any possibility to influence your future. Phrases like

    [...] GNU Lesser General Public License as published by the Free
    Software Foundation; either version 2.1 of the License, or (at your
    option) any later version.

    just invites him to screw you when it pleases him. Rip out the "any
    later version" part and make your own decisions when to use a
    different license since otherwise he can potentially do you or your
    work harm.

    Comment


    • #3
      I'm not sure what removal of sparc 32bit HOST support entails for TCG I would think it means TCG can no longer generate sparc instructions which would be rather bad for the cross platformness of TCG as a compiler backend then again its just a matter of adding it back,

      Comment

      Working...
      X