[Ffmpeg-devel] Porting to TI DM642 DSP
Thu Apr 21 05:21:31 CEST 2005
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
> 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
> obvious reason the compiler is complaining about _CODE_ACCESS and
> _LLONG_AVAILABLE not being defined?
> 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.
More information about the ffmpeg-devel