Update (2012)

I've proposed a new project called qcc that's a sequel to this. I think leveraging QEMU's code generation work is a much better approach than trying to reinvent support for every possible target.

I also I have permission from Fabrice Bellard to use his code under BSD license terms in the new project, which is another reason not to bother with the "MOB branch" of unmaintained drive-by contributions under different license terms and start from the version where I have a finite number of external contributions to triage.

Below the line is the previous explanation I posted when I stopped working on tinycc in 2008. My last two posts to the old tcc mailing list explain why I didn't go back there even when they finally switched to git:

This used to be the page for my fork of Fabrice Bellard's Tiny C Compiler, but I got sick of competing with a mostly dead CVS archive that nevertheless remained "official".

My old tinycc mercurial archive is still up, but it was last updated in April 2008, and it's GPLv2 while the CVS version is LGPL, so it's probably not much use.

My reasons for ending my fork are explained in this thread, in more detail than anyone could possibly be interested in, but here's a quick summary:

Every time I worked on my fork it inspired new work in the old CVS archive, and every time I set my fork aside the old project ground to a halt. Even though the old tcc project repeatedly stagnated whenever I stopped working on my fork for a few months, nobody wanted to work with me on my version because it wasn't "official".

The reason I didn't want to work directly on the "official" version is that it was tied to a CVS archive, which is not a real source control system. Among other things, my fork split up and renamed several files, something CVS just can't handle. CVS also has no concept of "changesets", so whever new patches were applied to CVS (mostly for Windows support), fishing those patches out of CVS to see if they're of interest to my fork was actively unpleasant. (CVS tracks files independently, so whenever a change touched multiple files I had to stitch together changesets by hand just to see what had happened. Some web interfaces can help with this, but Savannah's wasn't one of them.)

The real problem was patches that went into CVS without ever being posted to the mailing list, which included all of Grischka's windows support patches. (I don't do windows, so I had a hard time even _testing_ those, but lots of users cared. If I removed windows support entirely from my version it would just be one more reason for people to use the "official" CVS and clamor for my work on the rest of the compiler to be copied into CVS). My mental image for patches that went straight into CVS without going to the list was that the patch fell in a toilet, and I had to fish it out. And I was working on this compiler for _fun_...

I spent years suggesting that the official project migrate off of CVS to a real source control system (even Subversion would have been an improvement), but they refused to get rid of the CVS archive enshrined at the heart of their development process, even when development was clearly stagnant. I could never get to a point where I could both work on tinycc and ignore the old CVS archive, and putting more effort into my fork just meant I had to track two increasingly divergent codebases. (People sent me bug reports about the 0.9.24 release. Yeah, that release contained a lot of code copied out of my tree into CVS, but the release was based on CVS, not on my tree.)

By 2008 as CVS sank into obsolecense, TCC had clearly decided to go down with the ship. No matter how much work I put into my fork it would never eclipse the "official" tcc project (which could of course read my code to advance their tree). When I stopped work on my fork, the other project stopped, but when I started up again, so did they. All I was doing was keeping the CVS tree just active enough to exclipse mine, and I was tired of it.

Update: I'm told that after I unsubscribed from the mailing list they set up a GIT repository, so I checked the mailing list archive. It's just a mirror of the CVS: "If GIT is not for you, everything can be found in good old CVS as well." Of course CVS isn't going away, so pushing things like file renames (to move headers into a header subdirectory, to move each target's files into a subdirectory for that target) upstream isn't an option. They continue to miss the point, and I continue not to be interested. (Maybe if a full year went by without a single commit to CVS it would be dead enough that I could restart my version without having the dead one lurch zombie-like after me, but I could never be _sure_. Nope: let it die.)

(If you think that the current releases will be good enough forever, keep in mind that the current tcc doesn't produce x86-64 code. Even via's embedded x86 processors are 64 bit now, and -run doesn't work on a 64 bit host kernel if it's producing 32 bit code. CVS isn't the only way TCC is hopelessly stuck in the past; the 0.9.24 release doesn't even build on a 64 bit _host_ line mine did. I didn't come close to getting 64 bit target support finished in my version, but they never even _started_...)