[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nick
Subject: Re: [Tinycc-devel] Development/patches - subversion repository
Date: Wed, 13 Sep 2006 10:10:59 -0700
User-agent: Thunderbird (Windows/20060719)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]