[Ffmpeg-devel] Porting to TI DM642 DSP

[Rich Felker]

On Thu, Apr 21, 2005 at 11:36:47AM +0930, Patrick Noffke wrote:
> A couple extra problems I've stumbled across:
> 
> 1)  TI's compiler (Code Composer ver 2.21) doesn't support 64-bit long data 
> types (their longs are 40 bits).  I've seen a solution to this problem by 

this is rather unfortunate. can you use a different compiler?

> redefining int64 types as a structure of two 32-bit words, and defining a 
> bunch of macros for basic operations (add, subtract, multiply, divide, 
> shift, etc.).  If there are no better suggestions, I may have to go down 
> this road.  Of course, for compilers that support 64 bit types, the int64 
> types would remain as is, and the macros would use the native operators.

i'm pretty sure something like this won't get accepted into
mainstream. it's too ugly a hack... before doing something so evil i'd
suggest making a preprocessor for the compiler to do this crap for
you..

> 2)  The compiler is very fussy.  Implicit type casts from void * to another 
> pointer type is a compilation error.  For example, the return type of 
> malloc is void *, and a line like:

then it's not a c compiler. it's a c++ compiler trying to compile c
code as if it were c++, much like m$ crap.

> int * junk = malloc(100);
> 
> is a compilation error.  I need to explicitly cast to the left-hand type.  
> I tried various compile flags to make it less strict, in particular -pk, 
> which turns it into "K&R compatibility" mode.  But this results in other 
> errors in stdio.h and stdlib.h which are related to #if statements when the 
> operand of the #if hasn't been defined.  I need to look into this a bit 
> more, because I don't want to put in hundreds of explicit type casts 
> throughout the code.  It's a longshot, but does anyone out there know if 
> -pk is the correct way to deal with this, and when I do this, is there an 

it's not. are you sure the compiler isn't defaulting to some broken
c++ mode?

> obvious reason the compiler is complaining about _CODE_ACCESS and 
> _LLONG_AVAILABLE not being defined?

hm?

> IMPORTANT  ?  This email and any attachments may be confidential.  Any 
> retransmission, dissemination or other use of these materials by persons or 
> entities other than the intended recipient is prohibited.  If received in 
> error, please contact us and delete all copies.  Before opening or using 
> attachments, check them for viruses and defects.  Our liability is limited 
> to resupplying any affected attachments.  [Any representations or opinions 
> expressed in this email are those of the individual sender, and not 
> necessarily those of Vision Systems Limited.]

please do not send spam like this to the list. not only is it a waste
of disk space and bandwidth; it's also incredibly stupid since the
recipient is a publicly archived mailing list.

rich