Use of __int64 in C5510

Hi,

I am new to C5510 DSP programming. I have a big fixed point C code that I want to run on my C5510 DSK. The code use lots of __int64 and __int32 but when i compile it on CCS3.1 it gives an error :
"error: identifier "__int64" is undefined
error: identifier "__int32" is undefined"

I am stuck .. please help me in solving this problem ..

thanks in advance,
Ranjeeta Start a New Thread

Hi,,

if double is 64 bit then why the following MACRO is not giving correct
result

#define FORMAT_FRAC11(value, normval) (long)(value*normval)

if I call this macro as follows:

long y2;
y2 = FORMAT_FRAC11(7.07106781186547460000e-001, 0x7fffffff);

then on CCS it is giving y2 = 1518500224
and on visual studio C it is giving y2 = 1518500249

Why is there a loss of precision on CCS. Even with the use of "long double"
as:
#define FORMAT_FRAC11(value, normval) (DOUBLE)((long double)value*(long
double)normval)
, i am not getting the correct result on CCS

I have no idea of how to get correct results. I need the same results as i
am getting on visual studio C otherwise there will be loss of data which is
not permissible in my algorithm.

Waiting for a reply..

Thanks..

On 11 Apr 2007 05:17:38 -0700, x...@gmail.com
wrote:
>
> Hi Ranjeeta,
>
> Give careful consideration to the data type size when writing your code.
> The C55x compiler defines a size for each C data type (signed and nsigned):
> char - 16 bits
> short - 16 bits
> int - 16 bits
> long - 32 bits
> long long - 40 bits
> float - 32 bits
> double - 64 bits (Floating point values are in the IEEE format)
>
> When writing code to be used on DSP targets, define "generic" types for
> the standard C types. For your case, you could typedef as below:-
>
> typedef signed __int64 long long;
> typedef signed __int32 int;
>
> type long long has only 40-bit precision for C55x. You might encounter
> losses in fixed-point arithmetic. That's how you judge the losses
> (negligible?)
>
> Hope this help.
>
> Hi,
> >
> >I am new to C5510 DSP programming. I have a big fixed point C code that I
> want to run on my C5510 DSK. The code use lots of __int64 and __int32 but
> when i compile it on CCS3.1 it gives an error :
> >"error: identifier "__int64" is undefined
> >error: identifier "__int32" is undefined"
> >
> >I am stuck .. please help me in solving this problem ..
> >
> >thanks in advance,
> >Ranjeeta
> >
> > Start a New Thread

Ranjeeta-

> if double is 64 bit then why the following MACRO is not giving correct
> result
>
> #define FORMAT_FRAC11(value, normval) (long)(value*normval)
>
> if I call this macro as follows:
>
> long y2;
> y2 = FORMAT_FRAC11(7.07106781186547460000e-001, 0x7fffffff);
>
> then on CCS it is giving y2 = 1518500224
> and on visual studio C it is giving y2 = 1518500249
>
> Why is there a loss of precision on CCS. Even with the use of "long double"
> as:
> #define FORMAT_FRAC11(value, normval) (DOUBLE)((long double)value*(long
> double)normval)
> , i am not getting the correct result on CCS
>
> I have no idea of how to get correct results. I need the same results as i
> am getting on visual studio C otherwise there will be loss of data which is
> not permissible in my algorithm.

If I understand your example correctly, you are saying that CCS -- at compile-time, not at run-time -- is less
accurate in handling 64-bit floating-point arithmetic than Visual Studio. If that's correct, then I'm not surprised.
CCS has 100,000s of fewer users than VS over the years, so CCS likely has many "rough spots" not as well-polished as
VS.

I would report this to TI hotline and see what they say. Maybe they can offer a work-around or even a patch.

-Jeff

PS. Xenon's comments below have to do with run-time data types, not internal compiler arithmetic. My guess is that
CCS has accuracy equal to VS at run-time.

> On 11 Apr 2007 05:17:38 -0700, x...@gmail.com
> wrote:
>>
>> Hi Ranjeeta,
>>
>> Give careful consideration to the data type size when writing your code.
>> The C55x compiler defines a size for each C data type (signed and nsigned):
>> char - 16 bits
>> short - 16 bits
>> int - 16 bits
>> long - 32 bits
>> long long - 40 bits
>> float - 32 bits
>> double - 64 bits (Floating point values are in the IEEE format)
>>
>> When writing code to be used on DSP targets, define "generic" types for
>> the standard C types. For your case, you could typedef as below:-
>>
>> typedef signed __int64 long long;
>> typedef signed __int32 int;
>>
>> type long long has only 40-bit precision for C55x. You might encounter
>> losses in fixed-point arithmetic. That's how you judge the losses
>> (negligible?)
>>
>> Hope this help.
>>
>> Hi,
>> >
>> >I am new to C5510 DSP programming. I have a big fixed point C code that I
>> want to run on my C5510 DSK. The code use lots of __int64 and __int32 but
>> when i compile it on CCS3.1 it gives an error :
>> >"error: identifier "__int64" is undefined
>> >error: identifier "__int32" is undefined"
>> >
>> >I am stuck .. please help me in solving this problem ..
>> >
>> >thanks in advance,
>> >Ranjeeta Start a New Thread

Hi Ranjeeta,

you must typecast one of the operand to get correct
multiplication result on C55x. TI haven't fix this bug
yet..:(( go through the following code which clears
your doubt.

Int16 x, y;
Int32 Z;

// wrong
z = (Int32)(x*y);

// correct
z = (Int32)(Int32(x)*y);

// correct
z = (Int32)((Int32)x*(Int32)y);

Cheers,
-Lakshman

--- Jeff Brower wrote:

> Ranjeeta-
>
> > if double is 64 bit then why the following MACRO
> is not giving correct
> > result
> >
> > #define FORMAT_FRAC11(value, normval)
> (long)(value*normval)
> >
> > if I call this macro as follows:
> >
> > long y2;
> > y2 = FORMAT_FRAC11(7.07106781186547460000e-001,
> 0x7fffffff);
> >
> > then on CCS it is giving y2 = 1518500224
> > and on visual studio C it is giving y2 > 1518500249
> >
> > Why is there a loss of precision on CCS. Even with
> the use of "long double"
> > as:
> > #define FORMAT_FRAC11(value, normval)
> (DOUBLE)((long double)value*(long
> > double)normval)
> > , i am not getting the correct result on CCS
> >
> > I have no idea of how to get correct results. I
> need the same results as i
> > am getting on visual studio C otherwise there will
> be loss of data which is
> > not permissible in my algorithm.
>
> If I understand your example correctly, you are
> saying that CCS -- at compile-time, not at run-time
> -- is less
> accurate in handling 64-bit floating-point
> arithmetic than Visual Studio. If that's correct,
> then I'm not surprised.
> CCS has 100,000s of fewer users than VS over the
> years, so CCS likely has many "rough spots" not as
> well-polished as
> VS.
>
> I would report this to TI hotline and see what they
> say. Maybe they can offer a work-around or even a
> patch.
>
> -Jeff
>
> PS. Xenon's comments below have to do with run-time
> data types, not internal compiler arithmetic. My
> guess is that
> CCS has accuracy equal to VS at run-time.
>
> > On 11 Apr 2007 05:17:38 -0700, x...@gmail.com
>
> > wrote:
> >>
> >> Hi Ranjeeta,
> >>
> >> Give careful consideration to the data type size
> when writing your code.
> >> The C55x compiler defines a size for each C data
> type (signed and nsigned):
> >> char - 16 bits
> >> short - 16 bits
> >> int - 16 bits
> >> long - 32 bits
> >> long long - 40 bits
> >> float - 32 bits
> >> double - 64 bits (Floating point values are in
> the IEEE format)
> >>
> >> When writing code to be used on DSP targets,
> define "generic" types for
> >> the standard C types. For your case, you could
> typedef as below:-
> >>
> >> typedef signed __int64 long long;
> >> typedef signed __int32 int;
> >>
> >> type long long has only 40-bit precision for
> C55x. You might encounter
> >> losses in fixed-point arithmetic. That's how you
> judge the losses
> >> (negligible?)
> >>
> >> Hope this help.
> >>
> >> Hi,
> >> >
> >> >I am new to C5510 DSP programming. I have a big
> fixed point C code that I
> >> want to run on my C5510 DSK. The code use lots of
> __int64 and __int32 but
> >> when i compile it on CCS3.1 it gives an error :
> >> >"error: identifier "__int64" is undefined
> >> >error: identifier "__int32" is undefined"
> >> >
> >> >I am stuck .. please help me in solving this
> problem ..
> >> >
> >> >thanks in advance,
> >> >Ranjeeta Start a New Thread

Ranjeeta-
> There are lots of tables and I am loosing precision a lot on CCS. One possible
> solution is to to manually replce these tables with fixed point nos. directly
> (fixed point tables can be generated using a matlab script ) but that will take
> time.. Is there any other possible solution???

Did you ask the TI hotline yet? They usually give fairly sharp answers on
tools-related questions. This is a situation where they should know the work-around.
If you frame this as a "CCS bug" and point out the comparison to Visual Studio, you
might get an energetic response :-)

Myself, I don't know of a work-around. But now that the issue is clear, I wouldn't
be surprised if others on the group have some suggestions.

-Jeff
> You are right, I am using it at compile time. Actually I have a big Fixed point C
> code where I am using this macro:#define FORMAT_FRAC(value, normval)
> (long)(value*normval) to convert "floating point" tables and nos. to "fixed point"
> tables and nos. at "compile time" all through out the code like this: const long
> iQuant[128] > {FORMAT_FRAC(6.49519052838329000000e-001,0x7FFFFFFF),
> FORMAT_FRAC(7.32377602828622850000e-001,0x7FFFFFFF),
> FORMAT_FRAC(8.18487553356799680000e-001,0x7FFFFFFF),
> FORMAT_FRAC(9.07730471767363320000e-001,0x7FFFFFFF),
> FORMAT_FRAC(5.00000000000000000000e-001,0x7FFFFFFF),
> FORMAT_FRAC(5.47599965902345500000e-001,0x7FFFFFFF),
> FORMAT_FRAC(5.96621346626149520000e-001,0x7FFFFFFF),
> FORMAT_FRAC(6.47024061931818720000e-001,0x7FFFFFFF),
> FORMAT_FRAC(6.98771242968684310000e-001,0x7FFFFFFF),
> FORMAT_FRAC(7.51828824953692520000e-001,0x7FFFFFFF),
> FORMAT_FRAC(8.06165208719652030000e-001,0x7FFFFFFF),
> FORMAT_FRAC(8.61750976845254260000e-001,0x7FFFFFFF),
> FORMAT_FRAC(9.18558653543691820000e-001,0x7FFFFFFF),.....};
>
> There are lots of tables and I am loosing precision a lot on CCS. One possible
> solution is to to manually replce these tables with fixed point nos. directly
> (fixed point tables can be generated using a matlab script ) but that will take
> time.. Is there any other possible solution???
> ThanksRanjeeta On 4/12/07, Jeff Brower wrote:
>
> Ranjeeta-
>
> > if double is 64 bit then why the following MACRO is not giving correct
> > result
> >
> > #define FORMAT_FRAC11(value, normval) (long)(value*normval)
> >
> > if I call this macro as follows:
> >
> > long y2;
> > y2 = FORMAT_FRAC11(7.07106781186547460000e-001, 0x7fffffff);
> >
> > then on CCS it is giving y2 = 1518500224
> > and on visual studio C it is giving y2 = 1518500249
> >
> > Why is there a loss of precision on CCS. Even with the use of "long
> double"
> > as:
> > #define FORMAT_FRAC11(value, normval) (DOUBLE)((long
> double)value*(long
> > double)normval)
> > , i am not getting the correct result on CCS
> >
> > I have no idea of how to get correct results. I need the same results
> as i
> > am getting on visual studio C otherwise there will be loss of data
> which is
> > not permissible in my algorithm.
>
> If I understand your example correctly, you are saying that CCS -- at
> compile-time, not at run-time -- is less
> accurate in handling 64-bit floating-point arithmetic than Visual Studio.
> If that's correct, then I'm not surprised.
> CCS has 100,000s of fewer users than VS over the years, so CCS likely has
> many "rough spots" not as well-polished as
> VS.
>
> I would report this to TI hotline and see what they say. Maybe they can
> offer a work-around or even a patch.
>
> -Jeff
>
> PS. Xenon's comments below have to do with run-time data types, not
> internal compiler arithmetic. My guess is that
> CCS has accuracy equal to VS at run-time.
>
> > On 11 Apr 2007 05:17:38 -0700, x...@gmail.com
>
> > wrote:
> >>
> >> Hi Ranjeeta,
> >>
> >> Give careful consideration to the data type size when writing your
> code.
> >> The C55x compiler defines a size for each C data type (signed and
> nsigned):
> >> char - 16 bits
> >> short - 16 bits
> >> int - 16 bits
> >> long - 32 bits
> >> long long - 40 bits
> >> float - 32 bits
> >> double - 64 bits (Floating point values are in the IEEE format)
> >>
> >> When writing code to be used on DSP targets, define "generic" types
> for
> >> the standard C types. For your case, you could typedef as below:-
> >>
> >> typedef signed __int64 long long;
> >> typedef signed __int32 int;
> >>
> >> type long long has only 40-bit precision for C55x. You might encounter
>
> >> losses in fixed-point arithmetic. That's how you judge the losses
> >> (negligible?)
> >>
> >> Hope this help.
> >>
> >> Hi,
> >> >
> >> >I am new to C5510 DSP programming. I have a big fixed point C code
> that I
> >> want to run on my C5510 DSK. The code use lots of __int64 and __int32
> but
> >> when i compile it on CCS3.1 it gives an error :
> >> >"error: identifier "__int64" is undefined
> >> >error: identifier "__int32" is undefined"
> >> >
> >> >I am stuck .. please help me in solving this problem ..
> >> >
> >> >thanks in advance,
> >> >Ranjeeta Start a New Thread

Hi Jeff,

You are right, I am using it at compile time. Actually I have a big Fixed
point C code where I am using this macro:
#define FORMAT_FRAC(value, normval) (long)(value*normval)

to convert "floating point" tables and nos. to "fixed point" tables and nos.
at "compile time" all through out the code like this:
const long iQuant[128] {
FORMAT_FRAC(6.49519052838329000000e-001,0x7FFFFFFF),
FORMAT_FRAC(7.32377602828622850000e-001,0x7FFFFFFF),
FORMAT_FRAC(8.18487553356799680000e-001,0x7FFFFFFF),
FORMAT_FRAC(9.07730471767363320000e-001,0x7FFFFFFF),
FORMAT_FRAC(5.00000000000000000000e-001,0x7FFFFFFF),
FORMAT_FRAC(5.47599965902345500000e-001,0x7FFFFFFF),
FORMAT_FRAC(5.96621346626149520000e-001,0x7FFFFFFF),
FORMAT_FRAC(6.47024061931818720000e-001,0x7FFFFFFF),
FORMAT_FRAC(6.98771242968684310000e-001,0x7FFFFFFF),
FORMAT_FRAC(7.51828824953692520000e-001,0x7FFFFFFF),
FORMAT_FRAC(8.06165208719652030000e-001,0x7FFFFFFF),
FORMAT_FRAC(8.61750976845254260000e-001,0x7FFFFFFF),
FORMAT_FRAC(9.18558653543691820000e-001,0x7FFFFFFF),
.
.
.
.
.};

There are lots of tables and I am loosing precision a lot on CCS. One
possible solution is to to manually replce these tables with fixed point
nos. directly (fixed point tables can be generated using a matlab script )
but that will take time.. Is there any other possible solution???

Thanks
Ranjeeta
On 4/12/07, Jeff Brower wrote:
>
> Ranjeeta-
>
> > if double is 64 bit then why the following MACRO is not giving correct
> > result
> >
> > #define FORMAT_FRAC11(value, normval) (long)(value*normval)
> >
> > if I call this macro as follows:
> >
> > long y2;
> > y2 = FORMAT_FRAC11(7.07106781186547460000e-001, 0x7fffffff);
> >
> > then on CCS it is giving y2 = 1518500224
> > and on visual studio C it is giving y2 = 1518500249
> >
> > Why is there a loss of precision on CCS. Even with the use of "long
> double"
> > as:
> > #define FORMAT_FRAC11(value, normval) (DOUBLE)((long
> double)value*(long
> > double)normval)
> > , i am not getting the correct result on CCS
> >
> > I have no idea of how to get correct results. I need the same results as
> i
> > am getting on visual studio C otherwise there will be loss of data which
> is
> > not permissible in my algorithm.
>
> If I understand your example correctly, you are saying that CCS -- at
> compile-time, not at run-time -- is less
> accurate in handling 64-bit floating-point arithmetic than Visual
> Studio. If that's correct, then I'm not surprised.
> CCS has 100,000s of fewer users than VS over the years, so CCS likely has
> many "rough spots" not as well-polished as
> VS.
>
> I would report this to TI hotline and see what they say. Maybe they can
> offer a work-around or even a patch.
>
> -Jeff
>
> PS. Xenon's comments below have to do with run-time data types, not
> internal compiler arithmetic. My guess is that
> CCS has accuracy equal to VS at run-time.
>
> > On 11 Apr 2007 05:17:38 -0700, x...@gmail.com
> > wrote:
> >>
> >> Hi Ranjeeta,
> >>
> >> Give careful consideration to the data type size when writing your
> code.
> >> The C55x compiler defines a size for each C data type (signed and
> nsigned):
> >> char - 16 bits
> >> short - 16 bits
> >> int - 16 bits
> >> long - 32 bits
> >> long long - 40 bits
> >> float - 32 bits
> >> double - 64 bits (Floating point values are in the IEEE format)
> >>
> >> When writing code to be used on DSP targets, define "generic" types for
> >> the standard C types. For your case, you could typedef as below:-
> >>
> >> typedef signed __int64 long long;
> >> typedef signed __int32 int;
> >>
> >> type long long has only 40-bit precision for C55x. You might encounter
> >> losses in fixed-point arithmetic. That's how you judge the losses
> >> (negligible?)
> >>
> >> Hope this help.
> >>
> >> Hi,
> >> >
> >> >I am new to C5510 DSP programming. I have a big fixed point C code
> that I
> >> want to run on my C5510 DSK. The code use lots of __int64 and __int32
> but
> >> when i compile it on CCS3.1 it gives an error :
> >> >"error: identifier "__int64" is undefined
> >> >error: identifier "__int32" is undefined"
> >> >
> >> >I am stuck .. please help me in solving this problem ..
> >> >
> >> >thanks in advance,
> >> >Ranjeeta Start a New Thread

Hopefully I'm not speaking out of turn here (or out of ignorance, since
I rarely use floating-point on a 55x), but according to SPRU281F
(TMS320C55x C/C++ Compiler User's Guide), float, double and long double
types are all 32-bit. See page 5-6.

I would tend to believe the documentation given that a 23-bit mantissa
will give him exactly the loss of precision he observes.

In comparison, the assembly directives .double and .ldouble do declare
a 64-bit double-precision floating-point value (confirmed in SPRU280H
pg 4-48).

If this is truly a fixed-point algorithm and the macro is just for
coefficient initialization, there are cetainly ways around it.

Gary Start a New Thread

Hi Jeff..

I am going to ask TI hotline now and will reply back to u once i get a
workaround from them..

Thanks & Regards
Ranjeeta
On 4/16/07, Jeff Brower wrote:
>
> Ranjeeta-
> There are lots of tables and I am loosing precision a lot on CCS. One
> possible solution is to to manually replce these tables with fixed point
> nos. directly (fixed point tables can be generated using a matlab script )
> but that will take time.. Is there any other possible solution???
> Did you ask the TI hotline yet? They usually give fairly sharp answers on
> tools-related questions. This is a situation where they should know the
> work-around. If you frame this as a "CCS bug" and point out the comparison
> to Visual Studio, you might get an energetic response :-)
>
> Myself, I don't know of a work-around. But now that the issue is clear, I
> wouldn't be surprised if others on the group have some suggestions.
>
> -Jeff
> You are right, I am using it at compile time. Actually I have a big Fixed
> point C code where I am using this macro:#define FORMAT_FRAC(value,
> normval) (long)(value*normval) to convert "floating point" tables and
> nos. to "fixed point" tables and nos. at "compile time" all through out the
> code like this: const long iQuant[128] > {FORMAT_FRAC(6.49519052838329000000e-001,0x7FFFFFFF),
> FORMAT_FRAC(7.32377602828622850000e-001,0x7FFFFFFF),
> FORMAT_FRAC(8.18487553356799680000e-001,0x7FFFFFFF),
> FORMAT_FRAC(9.07730471767363320000e-001,0x7FFFFFFF),
> FORMAT_FRAC(5.00000000000000000000e-001,0x7FFFFFFF),
> FORMAT_FRAC(5.47599965902345500000e-001,0x7FFFFFFF),
> FORMAT_FRAC(5.96621346626149520000e-001,0x7FFFFFFF),
> FORMAT_FRAC(6.47024061931818720000e-001,0x7FFFFFFF),
> FORMAT_FRAC(6.98771242968684310000e-001,0x7FFFFFFF),
> FORMAT_FRAC(7.51828824953692520000e-001,0x7FFFFFFF),
> FORMAT_FRAC(8.06165208719652030000e-001,0x7FFFFFFF),
> FORMAT_FRAC(8.61750976845254260000e-001,0x7FFFFFFF),
> FORMAT_FRAC(9.18558653543691820000e-001,0x7FFFFFFF),.....};
>
> There are lots of tables and I am loosing precision a lot on CCS. One
> possible solution is to to manually replce these tables with fixed point
> nos. directly (fixed point tables can be generated using a matlab script )
> but that will take time.. Is there any other possible solution???
> ThanksRanjeeta On 4/12/07, *Jeff Brower*
> wrote:
> >
> > Ranjeeta-
> >
> > > if double is 64 bit then why the following MACRO is not giving correct
> >
> > > result
> > >
> > > #define FORMAT_FRAC11(value, normval) (long)(value*normval)
> > >
> > > if I call this macro as follows:
> > >
> > > long y2;
> > > y2 = FORMAT_FRAC11(7.07106781186547460000e-001, 0x7fffffff);
> > >
> > > then on CCS it is giving y2 = 1518500224
> > > and on visual studio C it is giving y2 = 1518500249
> > >
> > > Why is there a loss of precision on CCS. Even with the use of "long
> > double"
> > > as:
> > > #define FORMAT_FRAC11(value, normval) (DOUBLE)((long
> > double)value*(long
> > > double)normval)
> > > , i am not getting the correct result on CCS
> > >
> > > I have no idea of how to get correct results. I need the same results
> > as i
> > > am getting on visual studio C otherwise there will be loss of data
> > which is
> > > not permissible in my algorithm.
> >
> > If I understand your example correctly, you are saying that CCS -- at
> > compile-time, not at run-time -- is less
> > accurate in handling 64-bit floating-point arithmetic than Visual
> > Studio. If that's correct, then I'm not surprised.
> > CCS has 100,000s of fewer users than VS over the years, so CCS likely
> > has many "rough spots" not as well-polished as
> > VS.
> >
> > I would report this to TI hotline and see what they say. Maybe they can
> > offer a work-around or even a patch.
> >
> > -Jeff
> >
> > PS. Xenon's comments below have to do with run-time data types, not
> > internal compiler arithmetic. My guess is that
> > CCS has accuracy equal to VS at run-time.
> >
> > > On 11 Apr 2007 05:17:38 -0700, x...@gmail.com <
> > x...@gmail.com>
> > > wrote:
> > >>
> > >> Hi Ranjeeta,
> > >>
> > >> Give careful consideration to the data type size when writing your
> > code.
> > >> The C55x compiler defines a size for each C data type (signed and
> > nsigned):
> > >> char - 16 bits
> > >> short - 16 bits
> > >> int - 16 bits
> > >> long - 32 bits
> > >> long long - 40 bits
> > >> float - 32 bits
> > >> double - 64 bits (Floating point values are in the IEEE format)
> > >>
> > >> When writing code to be used on DSP targets, define "generic" types
> > for
> > >> the standard C types. For your case, you could typedef as below:-
> > >>
> > >> typedef signed __int64 long long;
> > >> typedef signed __int32 int;
> > >>
> > >> type long long has only 40-bit precision for C55x. You might
> > encounter
> > >> losses in fixed-point arithmetic. That's how you judge the losses
> > >> (negligible?)
> > >>
> > >> Hope this help.
> > >>
> > >> Hi,
> > >> >
> > >> >I am new to C5510 DSP programming. I have a big fixed point C code
> > that I
> > >> want to run on my C5510 DSK. The code use lots of __int64 and __int32
> > but
> > >> when i compile it on CCS3.1 it gives an error :
> > >> >"error: identifier "__int64" is undefined
> > >> >error: identifier "__int32" is undefined"
> > >> >
> > >> >I am stuck .. please help me in solving this problem ..
> > >> >
> > >> >thanks in advance,
> > >> >Ranjeeta
> >
> >
> > Start a New Thread

Gary-

> Hopefully I'm not speaking out of turn here (or out of ignorance, since
> I rarely use floating-point on a 55x), but according to SPRU281F
> (TMS320C55x C/C++ Compiler User's Guide), float, double and long double
> types are all 32-bit. See page 5-6.
>
> I would tend to believe the documentation given that a 23-bit mantissa
> will give him exactly the loss of precision he observes.
>
> In comparison, the assembly directives .double and .ldouble do declare
> a 64-bit double-precision floating-point value (confirmed in SPRU280H
> pg 4-48).
>
> If this is truly a fixed-point algorithm and the macro is just for
> coefficient initialization, there are cetainly ways around it.

The OP's issue is with CCS compiler. At compile-time CCS doesn't appear to be
handling floating-point arithmetic for defines, constants, macros, etc with more than
32-bit precision. I think now he's asking the TI hotline about it.

Note that for this issue the chip doesn't matter. The same problem exists for 67x or
any other TI device covered by CCS.

-Jeff Start a New Thread

Hi all,

I may be wrong, but it seem that there's no bug at all:
please see page 5-6 of spru281e.pdf that seem to be
the latest C55x's C compiler manual - am I right?

This page would possibly resolve both questions with doubles
and also with __int64.

In the installation of the C55x's code gen tools (ver 3.2.2)
that I have there's no definition of __int64 type at all,
is it really so? I was unable to find a structure that would
simulate 64 bit integers, however I did not dug too thouroughly :)

Rgds,

Andrew

> Re: Use of __int64 in C5510
> Posted by: "Jeff Brower" j...@signalogic.com jbrower888
> Date: Sun Apr 15, 2007 10:15 pm ((PDT))
>
> Ranjeeta-
>> There are lots of tables and I am loosing precision a lot on CCS. One possible
>> solution is to to manually replce these tables with fixed point nos. directly
>> (fixed point tables can be generated using a matlab script ) but that will take
>> time.. Is there any other possible solution???
>
> Did you ask the TI hotline yet? They usually give fairly sharp answers on
> tools-related questions. This is a situation where they should know the work-around.
> If you frame this as a "CCS bug" and point out the comparison to Visual Studio, you
> might get an energetic response :-)
>
> Myself, I don't know of a work-around. But now that the issue is clear, I wouldn't
> be surprised if others on the group have some suggestions.
>
> -Jeff
>> You are right, I am using it at compile time. Actually I have a big Fixed point C
>> code where I am using this macro:#define FORMAT_FRAC(value, normval)
>> (long)(value*normval) to convert "floating point" tables and nos. to "fixed point"
>> tables and nos. at "compile time" all through out the code like this: const long
>> iQuant[128] >> {FORMAT_FRAC(6.49519052838329000000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(7.32377602828622850000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(8.18487553356799680000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(9.07730471767363320000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(5.00000000000000000000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(5.47599965902345500000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(5.96621346626149520000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(6.47024061931818720000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(6.98771242968684310000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(7.51828824953692520000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(8.06165208719652030000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(8.61750976845254260000e-001,0x7FFFFFFF),
>> FORMAT_FRAC(9.18558653543691820000e-001,0x7FFFFFFF),.....};
>>
>> There are lots of tables and I am loosing precision a lot on CCS. One possible
>> solution is to to manually replce these tables with fixed point nos. directly
>> (fixed point tables can be generated using a matlab script ) but that will take
>> time.. Is there any other possible solution???
>> ThanksRanjeeta On 4/12/07, Jeff Brower wrote:
>>
>> Ranjeeta-
>>
>> > if double is 64 bit then why the following MACRO is not giving correct
>> > result
>> >
>> > #define FORMAT_FRAC11(value, normval) (long)(value*normval)
>> >
>> > if I call this macro as follows:
>> >
>> > long y2;
>> > y2 = FORMAT_FRAC11(7.07106781186547460000e-001, 0x7fffffff);
>> >
>> > then on CCS it is giving y2 = 1518500224
>> > and on visual studio C it is giving y2 = 1518500249
>> >
>> > Why is there a loss of precision on CCS. Even with the use of "long
>> double"
>> > as:
>> > #define FORMAT_FRAC11(value, normval) (DOUBLE)((long
>> double)value*(long
>> > double)normval)
>> > , i am not getting the correct result on CCS
>> >
>> > I have no idea of how to get correct results. I need the same results
>> as i
>> > am getting on visual studio C otherwise there will be loss of data
>> which is
>> > not permissible in my algorithm.
>>
>> If I understand your example correctly, you are saying that CCS -- at
>> compile-time, not at run-time -- is less
>> accurate in handling 64-bit floating-point arithmetic than Visual Studio.
>> If that's correct, then I'm not surprised.
>> CCS has 100,000s of fewer users than VS over the years, so CCS likely has
>> many "rough spots" not as well-polished as
>> VS.
>>
>> I would report this to TI hotline and see what they say. Maybe they can
>> offer a work-around or even a patch.
>>
>> -Jeff
>>
>> PS. Xenon's comments below have to do with run-time data types, not
>> internal compiler arithmetic. My guess is that
>> CCS has accuracy equal to VS at run-time.
>>
>> > On 11 Apr 2007 05:17:38 -0700, x...@gmail.com
>>
>> > wrote:
>> >>
>> >> Hi Ranjeeta,
>> >>
>> >> Give careful consideration to the data type size when writing your
>> code.
>> >> The C55x compiler defines a size for each C data type (signed and
>> nsigned):
>> >> char - 16 bits
>> >> short - 16 bits
>> >> int - 16 bits
>> >> long - 32 bits
>> >> long long - 40 bits
>> >> float - 32 bits
>> >> double - 64 bits (Floating point values are in the IEEE format)
>> >>
>> >> When writing code to be used on DSP targets, define "generic" types
>> for
>> >> the standard C types. For your case, you could typedef as below:-
>> >>
>> >> typedef signed __int64 long long;
>> >> typedef signed __int32 int;
>> >>
>> >> type long long has only 40-bit precision for C55x. You might encounter
>>
>> >> losses in fixed-point arithmetic. That's how you judge the losses
>> >> (negligible?)
>> >>
>> >> Hope this help.
>> >>
>> >> Hi,
>> >>>
>> >>>I am new to C5510 DSP programming. I have a big fixed point C code
>> that I
>> >> want to run on my C5510 DSK. The code use lots of __int64 and __int32
>> but
>> >> when i compile it on CCS3.1 it gives an error :
>> >>>"error: identifier "__int64" is undefined
>> >>>error: identifier "__int32" is undefined"
>> >>>
>> >>>I am stuck .. please help me in solving this problem ..
>> >>>
>> >>>thanks in advance,
>> >>>Ranjeeta
>>
> Start a New Thread