1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Pairing A C Compiler With QEMU's Code Generator

Compiler

Published on 18 November 2012 07:42 AM EST
Written by Michael Larabel in Compiler
2 Comments

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.

The QCC compiler is being worked on by Rob Landley, a developer with much compiler development experience that previously worked on early 64-bit TCC support. The QEMU CPU emulator has a code generator named TCG, which is short for Tiny Code Generator. The TCG generator translates code fragments from any target code supported by QEMU into a code representation that can be then executed on the host.

Using the Tiny Code Generator Interpreter (TCI) it allows running QEMU on any 32-bit or 64-bit host where as without this there is only support for the most prominent host CPU architectures. The Tiny Code Generator is part of the official QEMU release and works with x86/x86_64, ARM, MIPS, PowerPC, and other emulated environments.

The goal of QCC is to leverage QEMU's Tiny Code Generator/Interpreter rather than having to rewrite target code for all of these different architectures. The Tiny C Compiler right now just supports x86/x86_64 and some ARM support. It's certainly an interesting concept especially with QEMU working well already on most platforms and the TCC fork not having a huge development base.

Information on QCC can be found on Landley's home-page but there isn't too much information or code available right now as he's engaged on other projects too. QEMU's code generator is outlined on the QEMU Wiki.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. openSUSE Factory & Tumbleweed Are Merging
  2. More Fedora Delays: Fedora 21 Beta Slips
  3. Mono Brings C# To The Unreal Engine 4
  4. Coreboot Now Has Support For Intel Broadwell Hardware
  5. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  6. GTK+ Lands Experimental Backend For Mir Display Server
  7. Ubuntu 14.10 Officially Released
  8. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  9. Intel GVT-g GPU Virtualization Moves Closer
  10. GTK+ 3.16 To Bring Several New Features
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  4. Linux hacker compares Solaris kernel code:
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed