Re: [Tinycc-devel] Development/patches - subversion repository

[Nick]

Hi Guys,

I am not too concerned where the repository is hosed - I can provide 
free svn hosting and there are other services available. My main 
frustration has been seeing useful patches but with nothing applied to 
the main source tree. I think the solution is to open up write access to 
people actually working with TCC and making patches.

For a small project like TCC I figure it can work as without one person 
as a maintainer. I don't particularly like the single-person-maintainer 
model and that is why I am not volunteering to be that one person.

BTW - My open source history includes writing the gdb port for the ip2k, 
working with MythTV (HDHR port), and writing/porting ethernet and 
wireless drivers for Linux. My day job is working with an embedded 
application that runs on a range of embedded platforms. Past work 
includes micro-controller architecture and OS architecture.

I see three main strengths for TCC:

1) Scripting - using C as a scripting language.

2) Light-weight compiler that can be embedded into other applications so 
end-users can script the application.

3) The fixed register model is ideal for cross-platform intermediate 
code - see following.

Last year I did a proof of concept port of TCC to an ip3k processor. The 
trick was that TCC generated intermediate code that was fixed 
register/data memory model but with code that was instruction, size, and 
position independent. This code would be downloaded to the ip3k which 
would translate to native instructions and link as it was downloaded (ie 
the intermediate code was not stored on the ip3k). The idea was that the 
same intermediate code could be downloaded to our MIPS, ARM, and PowerPC 
based embedded systems. One TCC instruction would typically map to 1 or 
2 native instructions.

The register/memory model is pretty much fixed in TCC anyway so there is 
not much loss due to failure to optimize the use of registers for a 
specific chip.

The instruction generator was portable C code (only a few pages long for 
the ip3k) and so could be compiled as part of TCC (any host 
architecture) or compiled on the ip3k for translating the intermediate code.

Another big advantage is the ease of porting to a new architecture. I 
wrote a quick pre-processor so that the instruction patterns could be 
expressed as ip3k assembly code embedded in the C-code. The 
pre-processor would replace the assembly code with hex numbers so the 
resulting C-code was portable (no assembly code). The instruction 
translation was achieved by invoking gas for the particular 
architecture. This has the advantage of being able to quickly write a 
TCC port in a few pages of code without writing binary/hex numbers 
everywhere.

The big gotcha was how to handle debugging/debug information. That was 
beyond the scope of the proof of concept at that time.

The practical application of this was shelved at that time for non 
technical reasons but it looks like we will be picking it up again. It 
had me worried as TCC seemed to go quiet for quite a while. It is good 
to see people are still working with TCC.

The more immediate thing that would help TCC would be a CVS/SVN system 
that was opened up so that people can apply patches.

Nick