[Top][All Lists]

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

RE: [Tinycc-devel] C6x Port

From: TK
Subject: RE: [Tinycc-devel] C6x Port
Date: Sat, 8 Mar 2003 16:12:28 -0800

Sounds interesting.  I struggled with trying to simulate something like
that at the low level but finally gave up.  The 1 pass makes it tough.
I thought I might load parameters into registers and keep track of which
registers contained parameters, and then only push those if another
(nested) function call was encountered.  But then I'm embarrassed to
admit I pursued that quite far until it dawned on me that at run time
due to conditional branches that (nested) function call may or may not
be executed...

Hope you had a nice holiday.


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Fabrice Bellard
Sent: Friday, March 07, 2003 1:50 PM
To: address@hidden
Subject: Re: [Tinycc-devel] C6x Port

Thank you! Note that a small change in release 0.9.17 or 0.9.18 will be 
that function calls will be generated differently. The idea is to leave 
the function arguments in the 'vstack' and to let the processor specific

stuff do all the argument packing and function calls. On i386 it will be

slightly less efficient (because if more than three arguments are used a

temporary variable will be created on the stack before being pushed) but

it will ease the porting of TCC on all other architectures and allow 
correct implementation of alloca(), gcc builtin functions and inlining.


[Note: I will be on holidays during the next week - so don't be 
surprised if you get no answer from me].

Tom Kerekes wrote:
> Fabrice,
> You should be able to get the current source at:
> http://dynomotion.com/compiler.html
> I think the COFF formats for TI and Windows are very different so
> expect it to be useful for generating windows code.
> I tried to put #if (DO_C67) switches everywhere to identify the
> The generated code is probably 3X slower and larger than code
> by TI's compiler, because of a lot of unnecessary loads/stores, nops,
> and no real utilization of the parallel nature of the processor.  But
> for me, I find that for 99% of a DSP application I don't care about
> speed and the 1% of the code that is critical is usually hand
> Anyway, I took the simplest route to get it working at the expense of
> speed/efficiency.
> The TI compiler also expects the first 10 parameters of a function to
> passed in registers.  I tried to maintain values in registers, but
> running into problems (nested function calls), so I finally gave up
> just pushed them on the stack and popped them just before the call.
> Thanks again
> TK
> -----Original Message-----
> From: Fabrice Bellard [mailto:address@hidden 
> Sent: Friday, March 07, 2003 2:58 AM
> To: TK; address@hidden
> Subject: Re: [Tinycc-devel] C6x Port
> Hi,
> I am very interested to see your source code (TCC has never been
> before - and generating COFF instead of ELF is also very interesting -

> even for x86 it would be useful for a windows port). Can you send it
> me or to the mailing list or give a link ? Since TCC is released under

> the GPL you can do anything with it (including selling it) provided
> release the source code.
> Fabrice.
> TK wrote:
>>Thanks for writing an incredibly concise C compiler, the code is truly
>>I have attempted a TCC port to the TI C6711 DSP.  To my knowledge it
> is
>>the only available "free" compiler for the C6x.  (TI has an excellent
>>compiler called Code Composer, but it sells for $3-4K, and is somewhat
>>It generates a COFF output file that is fairly compatible with Code
>>Composer's.  Including function calls, debug line numbers, and global
>>Currently it compiles under MS VC++ 6.0 and runs under MS Windows, but
>>it wouldn't be hard to change back to Linux.  If anyone has any
> interest
>>I can post the code somewhere.
>>I am hoping to distribute this with a C6x DSP board I am designing.
>>Would this be OK?  Are their any legal issues?
>>Thanks again


Tinycc-devel mailing list

reply via email to

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