TCC has two even more cool things:

1) a library that lets you compile C code within a process, relocate it and execute it. This is rather faster than shelling out to run gcc to create a shared object and open it using dlopen.

2) an awesome 2004 demonstration where TCC was used as a boot loader. Take the Linux kernel source (slightly modified to remove some of the gccisms), add TCCBOOT and reboot the machine: as part of the boot process TCC recompiles the kernel and the continue to execute the freshly compiled kernel -- all in 15 seconds: http://bellard.org/tcc/tccboot.html

How would you like to have a REPL for kernel development, like on the Lisp Machines? (Yes, that's a rhetorical question!)

Take TCC with your point 1 above. Mix it with the ideas from Schemix ( http://abstractnonsense.com/schemix/ ). Now you can iteratively development a kernel driver!

I hacked on Schemix a while back, updating it to 2.6 module system (unfortunately lost the source code before it got uploaded). It's a seemingly great idea but what good is scheme code if you have to rewrite in a different language for the final version?

I really love Fabrice, but "TCC" will, forever, remain Turbo C, not Tiny C.

DOS weenie pride!

Ctrl+F9 ftw.

An interesting thing about tcc is how fast it is compared to gcc. If you can use it, that might be a great advantage in development times.

That's precisely why I sometimes use it. And that running code through another compiler can sometimes highlight issues that went previously unnoticed.

One thing that was sad was to see how ugly the forking situation got: http://www.landley.net/code/tinycc/

When I was using tcc a lot I used the tinycc fork as it had fixed bugs I was encountering. It's a shame that things didn't work out amicably.