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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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 <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
> >
> >

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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 <j...@signalogic.com> 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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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 <j...@signalogic.com>
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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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 <j...@signalogic.com> 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

(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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 <j...@signalogic.com> 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* <j...@signalogic.com>
> 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
> >
> >
> >

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

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 <j...@signalogic.com>
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
>>
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Andrew-

> 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 :)

Pg 5-6 in SPRU281e refers to run-time data types and arithmetic precision, not
compile-time.

I think it's reasonable that a modern compiler should handle 64-bit
floating-point precision during compilation. 
What's the point of losing precision in macros, constants, defines, etc?  Such
calculations are completely internal to
the compiler and not limited by any device characteristics.

-Jeff

>> 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
<j...@signalogic.com> 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
>>>
>>>
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Hi Jeff,

All are good points, that are not to disagree with. I was thinking
a bit different:

As I can reason it at the moment (there might be someone from TI
that's monitoring this board and might want to add a comment?)
the compiler on compile time simulates exactly what the hardware
(plus all the run-time floating point math simulation software --
sorry for being tautologic here) is capable to do on the run-time.

>From that point of view (well, kind of a minimalistic one :) the
logic of the compiler seem to be reasonable: run time generated
numbers would agree in accuracy with compile time generated
numbers.

But to make my stand clear I would yell: compiler developers, give
us the sinful :) full accuracy and document this in the manuals!

Rgds,

Andrew

> Date: 17-Apr-2007 09:46:27 -0700
> From: Jeff Brower <j...@signalogic.com> Andrew-
>
>> 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 :)
>
> Pg 5-6 in SPRU281e refers to run-time data types and arithmetic precision,
not compile-time.
>
> I think it's reasonable that a modern compiler should handle 64-bit
floating-point precision during compilation.
> What's the point of losing precision in macros, constants, defines, etc? 
Such calculations are completely internal to
> the compiler and not limited by any device characteristics.
>
> -Jeff
>
>>> 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
<j...@signalogic.com> 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
>>>>
>>>>
>>>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Hi all,

> Re: Use of __int64 in C5510
> Posted by: "Jeff Brower" j...@signalogic.com jbrower888
> Date: Mon Apr 16, 2007 8:12 am ((PDT))
>
> 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.

I just tested this with 67xx cgt. It gives a number consistent with 64 bit
double precision. It seem that TI's compilers performs consistently with a
chip capabilities. If 64 bit floats are not supported in 55xx chips, then
the compiler works with 32 bit floats -- on x86 :)

The C6000 silicons do have 64 bit floats support, hence the corresponding
compiler process them on compile time.

In any situation, Gary's post mentioned quite a valid workaround :)

Rgds,

Andrew

> -Jeff
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

The long long type is actually a 40-bit number with the C55xx series.

To avoid confusion, it is nice to use typedefs

typedef signed long long int40_t;
typedef unsigned long long uint40_t;

On Mon, 16 Apr 2007, Andrew Nesterov wrote:

> 
> 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
<j...@signalogic.com> 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
> >>
> >>
> >

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Andrew-

> > 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.
> 
> I just tested this with 67xx cgt. It gives a number consistent with 64 bit
> double precision. It seem that TI's compilers performs consistently with a
> chip capabilities. If 64 bit floats are not supported in 55xx chips, then
> the compiler works with 32 bit floats -- on x86 :)

It might be this way, but if so it doesn't make sense to me.  It's the same CCS
internal compiler for devices.  There may be a series of calculations involving
macros, defines, and other constants before any result is assigned to actual
run-time
code -- before the chip type matters.  Why should a 32-bit run-time variable be
assigned a value that's already lost precision in its last couple of digits? 
Why
lose precision before code even runs?

I don't see valid reasons why TI would fail to maintain a high level of
precision
during intermediate compilation steps.

-Jeff

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Hi All,

I had contacted TI technical support regarding 64 bit floating point nos.
(at compile time) and this is the reply that I got:
"Regarding your query about the Floating Point Round Off, please note that
this is an
expected behavior with CCS. This is because, CCS follows C89 standard while
Visual
Studio follows IEEE754 standard. TI has already recognized the significance
of the
IEEE754 standard and is in the process of implementing it in the future
tools.

However, presently there is no alternative or and work around for this."

Thanks
Ranjeeta

On 17 Apr 2007 08:52:12 -0700, Jeff Brower <j...@signalogic.com> wrote:
>
>   Andrew-
>
> > 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 :)
>
> Pg 5-6 in SPRU281e refers to run-time data types and arithmetic precision,
> not compile-time.
>
> I think it's reasonable that a modern compiler should handle 64-bit
> floating-point precision during compilation.
> What's the point of losing precision in macros, constants, defines, etc?
> Such calculations are completely internal to
> the compiler and not limited by any device characteristics.
>
> -Jeff
>
> >> Re: Use of __int64 in C5510
> >> Posted by: "Jeff Brower"
j...@signalogic.com<jbrower%40signalogic.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
<j...@signalogic.com<jbrower%40signalogic.com>>
> 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<xenonexer%40gmail.com>
> >>> <x...@gmail.com <xenonexer%40gmail.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
> >>>
> >>>
> >>
> >
> >
> > 
> >
> >
> >
> 

(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Hi Jeff,

> Date: Wed, 18 Apr 2007 17:27:43 -0500
> From: Jeff Brower <j...@signalogic.com>
> To: Andrew Nesterov <a...@techemail.com>
> Cc: c...@yahoogroups.com
> 
> Andrew-
>
>>> 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.
>>
>> I just tested this with 67xx cgt. It gives a number consistent with 64
bit
>> double precision. It seem that TI's compilers performs consistently
with a
>> chip capabilities. If 64 bit floats are not supported in 55xx chips,
then
>> the compiler works with 32 bit floats -- on x86 :)
>
> It might be this way, but if so it doesn't make sense to me.  It's the same
CCS
> internal compiler for devices.  There may be a series of calculations
involving
> macros, defines, and other constants before any result is assigned to
actual run-time
> code -- before the chip type matters.  Why should a 32-bit run-time
variable be
> assigned a value that's already lost precision in its last couple of
digits?  Why
> lose precision before code even runs?
>
> I don't see valid reasons why TI would fail to maintain a high level of
precision
> during intermediate compilation steps.

What do you mean by "it is the same CCS internal compiler for
devices"?
There are different trees for C6000, C5000, C2000, quite different C3x and C4x,
ARM (MSP and C64+/DM64+ cores) code gen tools. All above are IEEE754 floating
point, except C3x and C4x that use TI's internal floating point format -
well, of course you know about all the differences in these architectures :)

I was writing one possible explanation for using 32 bit floats on compile time
in my previous email; can we look at the same problem from yet another point
of view:

Integer arithmetic (in contrast with floating point one) is bit exact. This
implies that an integer calculated on compile time has to compare exactly with
the same integer obtained on run time. But they would differ if compile time
constant were calculated using more than 32 bit precision float number!

As far as I can see it now, this might be the only reason for using 32 bit
floats on compile time. From that point of view there is no connection at
all with number of bits for integer number representation and for floating
point number representation, which is also consistent with the C standard.

Does this make sense?

Rgds,

Andrew

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Andrew-

> What do you mean by "it is the same CCS internal compiler for
devices"?
> There are different trees for C6000, C5000, C2000, quite different C3x and
C4x,
> ARM (MSP and C64+/DM64+ cores) code gen tools. All above are IEEE754
floating
> point, except C3x and C4x that use TI's internal floating point format -
> well, of course you know about all the differences in these architectures
:)

Sorry I wasn't clear.  I meant the same internal CCS compiler engine is used
for
C5000 and C6000 devices.  I was trying to say that because those two families
represent a wide mix of word-length and fix-point vs. floating-point devices,
it
seems unlikely TI would program CCS to handle internal arithmetic (defines,
macros,
etc) differently for each device.

> I was writing one possible explanation for using 32 bit floats on compile
time
> in my previous email; can we look at the same problem from yet another
point
> of view:
> 
> Integer arithmetic (in contrast with floating point one) is bit exact.
This
> implies that an integer calculated on compile time has to compare exactly
with
> the same integer obtained on run time.

Wait please... are not the rules for operator precedence and promotion the same
for
compiler constant expressions as for C code?  In that case, the programmer can
control precision, depending on how macros and constants are written /
expressed.

For compiler constant expressions, it should be a case of taking advantage of
64-bit
floating-point precision if you need it, or forcing less precision if you need
that. 
CCS shouldn't place a limit on either.

-Jeff

> But they would differ if compile time
> constant were calculated using more than 32 bit precision float number!
> 
> As far as I can see it now, this might be the only reason for using 32 bit
> floats on compile time. From that point of view there is no connection at
> all with number of bits for integer number representation and for floating
> point number representation, which is also consistent with the C standard.
> 
> Does this make sense?
> 
> Rgds,

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Andrew-

Yep, always waiting for new TI tools release!  Some things never change, even
after 15 years :-)

-Jeff

> Hi Jeff,
>
>>> What do you mean by "it is the same CCS internal compiler for
devices"?
>>> There are different trees for C6000, C5000, C2000, quite different
C3x and C4x,
>>> ARM (MSP and C64+/DM64+ cores) code gen tools. All above are
IEEE754 floating
>>> point, except C3x and C4x that use TI's internal floating point
format -
>>> well, of course you know about all the differences in these
architectures :)
>>
>> Sorry I wasn't clear.  I meant the same internal CCS compiler engine is
used for
>> C5000 and C6000 devices.  I was trying to say that because those two
families
>> represent a wide mix of word-length and fix-point vs. floating-point
devices, it
>> seems unlikely TI would program CCS to handle internal arithmetic
(defines, macros,
>> etc) differently for each device.
>
> Nevermind :) I think that now I've got what you meant. Yes, both compilers
> translate a C code first of all. But apparently (and TI support answer
that
> Ranjeeta has forwarded into here seem to confirm that) the two handle
floats
> differently - with respect to how the two devices' hardware and run time
> support provided by that same compilers are capable to treat floats.
>
>>> I was writing one possible explanation for using 32 bit floats on
compile time
>>> in my previous email; can we look at the same problem from yet
another point
>>> of view:
>>>
>>> Integer arithmetic (in contrast with floating point one) is bit
exact. This
>>> implies that an integer calculated on compile time has to compare
exactly with
>>> the same integer obtained on run time.
>>
>> Wait please... are not the rules for operator precedence and promotion
the same for
>> compiler constant expressions as for C code?  In that case, the
programmer can
>> control precision, depending on how macros and constants are written /
expressed.
>
> Yes, I think that they should be the same, but based on what I know on
compiler
> design, a compiler should be consistent with its target run time and
hardware -
> this seem to be the point where we disagree?
>
> With floating point calculations, a number can be computed on compile
> time and used as a termination parameter for a run time algorithm, usually
an
> iterative one (here I consider an imaginary situation, but most of the
articles
> I saw on floating point calculations would use same arguments), and due to
> the difference in precision utilized on compile time and run time such a
> process has good chances to never terminate. It enters an inifinite loop
> because the standard test to terminate iterations
>
>   abs(cnst_run_time - cnst_compile_time) <= eps*abs(cnst_compile_time)
>
> might never become true.
>
> So I think that for a compiler to be "conservative" with floating
point
> calculations is a safer strategy.
>
> At the moment, when the question has been stated, the only thing we can do
is
> to wait for next releases of C55xx code generation tools.
>
> Thanks for this discussion and best regards,
>
> Andrew
>

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

Hi Jeff,

>> What do you mean by "it is the same CCS internal compiler for
devices"?
>> There are different trees for C6000, C5000, C2000, quite different C3x
and C4x,
>> ARM (MSP and C64+/DM64+ cores) code gen tools. All above are IEEE754
floating
>> point, except C3x and C4x that use TI's internal floating point format
-
>> well, of course you know about all the differences in these
architectures :)
>
> Sorry I wasn't clear.  I meant the same internal CCS compiler engine is
used for
> C5000 and C6000 devices.  I was trying to say that because those two
families
> represent a wide mix of word-length and fix-point vs. floating-point
devices, it
> seems unlikely TI would program CCS to handle internal arithmetic (defines,
macros,
> etc) differently for each device.

Nevermind :) I think that now I've got what you meant. Yes, both compilers
translate a C code first of all. But apparently (and TI support answer that
Ranjeeta has forwarded into here seem to confirm that) the two handle floats
differently - with respect to how the two devices' hardware and run time
support provided by that same compilers are capable to treat floats.

>> I was writing one possible explanation for using 32 bit floats on
compile time
>> in my previous email; can we look at the same problem from yet another
point
>> of view:
>>
>> Integer arithmetic (in contrast with floating point one) is bit exact.
This
>> implies that an integer calculated on compile time has to compare
exactly with
>> the same integer obtained on run time.
>
> Wait please... are not the rules for operator precedence and promotion the
same for
> compiler constant expressions as for C code?  In that case, the programmer
can
> control precision, depending on how macros and constants are written /
expressed.

Yes, I think that they should be the same, but based on what I know on compiler
design, a compiler should be consistent with its target run time and hardware -
this seem to be the point where we disagree?

With floating point calculations, a number can be computed on compile
time and used as a termination parameter for a run time algorithm, usually an
iterative one (here I consider an imaginary situation, but most of the articles
I saw on floating point calculations would use same arguments), and due to
the difference in precision utilized on compile time and run time such a
process has good chances to never terminate. It enters an inifinite loop
because the standard test to terminate iterations

  abs(cnst_run_time - cnst_compile_time) <= eps*abs(cnst_compile_time)

might never become true.

So I think that for a compiler to be "conservative" with floating
point
calculations is a safer strategy.

At the moment, when the question has been stated, the only thing we can do is
to wait for next releases of C55xx code generation tools.

Thanks for this discussion and best regards,

Andrew

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )

> Yep, always waiting for new TI tools release!  Some things never change, 
> even after 15 years :-)

And others get even worse :) -- the entropy law...

Cheers,

Andrew

______________________________
New Code Sharing Section now Live on DSPRelated.com. Learn about the Reward Program for Contributors here.



(You need to be a member of c55x -- send a blank email to c55x-subscribe@yahoogroups.com )