[Ffmpeg-devel] Porting to TI DM642 DSP
Thu Apr 21 04:06:47 CEST 2005
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 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.
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:
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 obvious reason the compiler is complaining about _CODE_ACCESS and _LLONG_AVAILABLE not being defined?
Senior Software Engineer
Vision Fire & Security
14 Park Way
Mawson Lakes SA 5095
Phone: +61 8 8462 1224
Fax: +61 8 8462 1001
Email: patrick.noffke at adpro.com.au
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.]
More information about the ffmpeg-devel