Dear all: I use the Product:"TI TMS320VC5510", related link: http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html In this environment, its data type "double" is 4 bytes, and it doesn't support 8bytes-double. The precision is not good enough for me. For example,in this environment, double dvar = 0.123456789999; the compiler compiles the dvar : 0.1234568 caused by the length of the double is 4 bytes,not 8bytes. But I need more precision,like the 0.123456789999. How to improve the precision error??? Please give me a hand and thx a lot.
How to improve the precision in TI TMSVC5510 ????
Started by ●September 8, 2004
Reply by ●September 8, 20042004-09-08
Auronc wrote:> Dear all: > I use the Product:"TI TMS320VC5510", related link: > http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html > > In this environment, its data type "double" is 4 bytes, and it doesn't > support 8bytes-double. The precision is not good enough for me. > > For example,in this environment, > double dvar = 0.123456789999; > the compiler compiles the dvar : 0.1234568 > caused by the length of the double is 4 bytes,not 8bytes. > > But I need more precision,like the 0.123456789999. > > How to improve the precision error??? > Please give me a hand and thx a lot.I assume you're using Code Composter. CC for the '28xx also violates the ANSI standard in this way, but it will give you a 64-bit floating point if you use type "long double". I cannot adequately express my continuing dismay at this failure of TI to conform to the ANSI standard -- it isn't a hard thing to follow, and one breaks innumerable code libraries by using 32-bit "double". Oh well, just another thing to take into account the next time I select a processor. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 9, 20042004-09-09
"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message news:10jvgpcmjp5erc5@corp.supernews.com...> Auronc wrote: > >> Dear all: >> I use the Product:"TI TMS320VC5510", related link: >> http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html In this >> environment, its data type "double" is 4 bytes, and it doesn't >> support 8bytes-double. The precision is not good enough for me. >> >> For example,in this environment, >> double dvar = 0.123456789999; >> the compiler compiles the dvar : 0.1234568 >> caused by the length of the double is 4 bytes,not 8bytes. >> >> But I need more precision,like the 0.123456789999. >> >> How to improve the precision error??? >> Please give me a hand and thx a lot. > > I assume you're using Code Composter. CC for the '28xx also violates the > ANSI standard in this way, but it will give you a 64-bit floating point if > you use type "long double". > > I cannot adequately express my continuing dismay at this failure of TI to > conform to the ANSI standard -- it isn't a hard thing to follow, and one > breaks innumerable code libraries by using 32-bit "double". > > Oh well, just another thing to take into account the next time I select a > processor. > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.comTim, This gets worse yet for the 55xx. I just looked in the 55xx C/C++ Compiler Guide and apparently float = double = long double = 32-bit. I don't get why they even bother defining them! I recommend that in your code you create a file of #defines for all the floats, ints, etc. It's pretty common to see "int" be 16-bit on some processors and 32-bit on others. If you always use things like Int32 or Uint16 and have a file of #defines for the specific processor that will help you from getting burned if you switch processors. Auronc, I'm curious why you're not using a floating point device like the 6713? That has hardware support for 64-bit double precision floating point. The 55xx DSPs were designed to do 16-bit fixed point math. Even a 28xx DSP might be better for this as it architecture more easily allows for 64-bit operations. Also it has assembly instructions that will speed up tasks like scaling when emulating floating point in software as you are doing. Brad
Reply by ●September 9, 20042004-09-09
Tim Wescott wrote:> Auronc wrote: > >> Dear all: >> I use the Product:"TI TMS320VC5510", related link: >> http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html >> In this environment, its data type "double" is 4 bytes, and it doesn't >> support 8bytes-double. The precision is not good enough for me. >> >> For example,in this environment, >> double dvar = 0.123456789999; >> the compiler compiles the dvar : 0.1234568 >> caused by the length of the double is 4 bytes,not 8bytes. >> >> But I need more precision,like the 0.123456789999. >> >> How to improve the precision error??? >> Please give me a hand and thx a lot. > > > I assume you're using Code Composter. CC for the '28xx also violates > the ANSI standard in this way, but it will give you a 64-bit floating > point if you use type "long double". > > I cannot adequately express my continuing dismay at this failure of TI > to conform to the ANSI standard -- it isn't a hard thing to follow, > and one breaks innumerable code libraries by using 32-bit "double". > > Oh well, just another thing to take into account the next time I > select a processor. >It might be annoying, because it doesn't follow common practice. However, I don't see how it contravenes the ANSI spec. The ANSI spec does not define the length, or format (i.e. whether it must be IEEE754 or something else), of floating numbers. float is generally 32 bits. double is widely, but far from exclusively, 64 bits. long double is very variable around the industry. 80 bits and 128 bits are common lengths for long double, but 64 and 32 are not unknown. Some compilers provide a compilation switch to select if double is 32 bits or 64 bits. The GCC implementation for some embedded controllers provides that. Regards, Steve
Reply by ●September 9, 20042004-09-09
"Brad Griffis" <bradgriffis@hotmail.com> writes:> [...] > Even a 28xx DSP might be better for this as it architecture > more easily allows for 64-bit operations.How so? -- % Randy Yates % "How's life on earth? %% Fuquay-Varina, NC % ... What is it worth?" %%% 919-577-9882 % 'Mission (A World Record)', %%%% <yates@ieee.org> % *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●September 9, 20042004-09-09
Brad Griffis wrote:>"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message >news:10jvgpcmjp5erc5@corp.supernews.com... > > >>Auronc wrote: >> >> >> >>>Dear all: >>> I use the Product:"TI TMS320VC5510", related link: >>>http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html In this >>>environment, its data type "double" is 4 bytes, and it doesn't >>>support 8bytes-double. The precision is not good enough for me. >>> >>>For example,in this environment, >>> double dvar = 0.123456789999; >>>the compiler compiles the dvar : 0.1234568 >>>caused by the length of the double is 4 bytes,not 8bytes. >>> >>>But I need more precision,like the 0.123456789999. >>> >>>How to improve the precision error??? >>>Please give me a hand and thx a lot. >>> >>> >>I assume you're using Code Composter. CC for the '28xx also violates the >>ANSI standard in this way, but it will give you a 64-bit floating point if >>you use type "long double". >> >>I cannot adequately express my continuing dismay at this failure of TI to >>conform to the ANSI standard -- it isn't a hard thing to follow, and one >>breaks innumerable code libraries by using 32-bit "double". >> >>Oh well, just another thing to take into account the next time I select a >>processor. >> >>-- >> >>Tim Wescott >>Wescott Design Services >>http://www.wescottdesign.com >> >> > >Tim, > >This gets worse yet for the 55xx. I just looked in the 55xx C/C++ Compiler >Guide and apparently float = double = long double = 32-bit. I don't get why >they even bother defining them! > >I recommend that in your code you create a file of #defines for all the >floats, ints, etc. It's pretty common to see "int" be 16-bit on some >processors and 32-bit on others. If you always use things like Int32 or >Uint16 and have a file of #defines for the specific processor that will help >you from getting burned if you switch processors. > >Why do people still want to do this, when standard names for these things were defined in C99? Include stdint.h, use uint16_t, int32_t, etc. and follow the standards. Its bad enough that C89 didn't specify standard names for these things. Now we have them, please use them. Regards, Steve
Reply by ●September 9, 20042004-09-09
Yes, I use code composer in the C5510. But it doesn't support "long double".
For example:
long double ldvar =1.23456789;
In the debug window, the value of ldvar is
5.273265966952796e-315
why???
Any library could be download for simulating 8bytes double???
>Tim Wescott <tim@wescottnospamdesign.com> wrote in message >news:<10jvgpcmjp5erc5@corp.supernews.com>...
>
> I assume you're using Code Composter. CC for the '28xx also violates
> the ANSI standard in this way, but it will give you a 64-bit floating
> point if you use type "long double".
>
> I cannot adequately express my continuing dismay at this failure of TI
> to conform to the ANSI standard -- it isn't a hard thing to follow, and
> one breaks innumerable code libraries by using 32-bit "double".
>
> Oh well, just another thing to take into account the next time I select
> a processor.
Reply by ●September 9, 20042004-09-09
"Randy Yates" <yates@ieee.org> wrote in message news:wtz3lxyo.fsf@ieee.org...> "Brad Griffis" <bradgriffis@hotmail.com> writes: >> [...] >> Even a 28xx DSP might be better for this as it architecture >> more easily allows for 64-bit operations. > > How so? > -- > % Randy Yates % "How's life on earth? > %% Fuquay-Varina, NC % ... What is it worth?" > %%% 919-577-9882 % 'Mission (A World Record)', > %%%% <yates@ieee.org> % *A New World Record*, ELO > http://home.earthlink.net/~yatescrWell on the one hand the 55xx has four 40-bit accumulators which work great for doing 16-bit MACs. The 28xx on the other hand has a 32-bit accumulator and a 32-bit product register which for some instructions can work in a concatenated fashion to act like a 64-bit accumulator. Of course a 67xx is going to whoop either of these. :) Brad
Reply by ●September 9, 20042004-09-09
Tim Wescott wrote:> Auronc wrote: > >> Dear all: >> I use the Product:"TI TMS320VC5510", related link: >> http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html >> In this environment, its data type "double" is 4 bytes, and it doesn't >> support 8bytes-double. The precision is not good enough for me. >> >> For example,in this environment, >> double dvar = 0.123456789999; >> the compiler compiles the dvar : 0.1234568 >> caused by the length of the double is 4 bytes,not 8bytes. >> >> But I need more precision,like the 0.123456789999. >> >> How to improve the precision error??? >> Please give me a hand and thx a lot. > > > I assume you're using Code Composter. CC for the '28xx also violates > the ANSI standard in this way, but it will give you a 64-bit floating > point if you use type "long double". > > I cannot adequately express my continuing dismay at this failure of TI > to conform to the ANSI standard -- it isn't a hard thing to follow, and > one breaks innumerable code libraries by using 32-bit "double". > > Oh well, just another thing to take into account the next time I select > a processor.The ANSI standard defines a byte as the larger of an addressable memory unit, the size of a character, and eight bits. It defines an int as at least 16 bits, a double not smaller than an int, and a long double not smaller than a double. The 'C5510's C compiler conforms to all these requirements. Since the smallest addressable memory unit is 16 bits, sizeof(char) and sizeof(int) will both return 1. Apparently, sizeof(long) is also 1; that too is conforming. Any code that breaks wasn't written with portably in mind. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●September 9, 20042004-09-09
Steve Underwood wrote:> Brad Griffis wrote: > >> "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message >> news:10jvgpcmjp5erc5@corp.supernews.com... >> >> >>> Auronc wrote: >>> >>> >>> >>>> Dear all: >>>> I use the Product:"TI TMS320VC5510", related link: >>>> http://focus.ti.com/docs/prod/folders/print/tms320vc5510.html In >>>> this environment, its data type "double" is 4 bytes, and it doesn't >>>> support 8bytes-double. The precision is not good enough for me.What, exactly, do you want double precision floats for? Is it for a run-time computation of some sort, or for a compile time constant evaluation? If the latter, you might be better to compute and quantize those coefficients off-line with something like a Matlab script, for clarity, and just include the resulting values as hex constants in your C program. You do know that the C5510 is a 16-bit fixed-point processor, don't you? Any use of floating point at all, at run-time, is doomed to be appallingly slow, as it will necessarily be evaluated in some floating point software library.>>>> For example,in this environment, >>>> double dvar = 0.123456789999; >>>> the compiler compiles the dvar : 0.1234568 >>>> caused by the length of the double is 4 bytes,not 8bytes. >>>> >>>> But I need more precision,like the 0.123456789999. >>>> >>>> How to improve the precision error??? >>>> Please give me a hand and thx a lot. >>>> >>> >>> I assume you're using Code Composter. CC for the '28xx also violates >>> the ANSI standard in this way, but it will give you a 64-bit floating >>> point if you use type "long double". >>> >>> I cannot adequately express my continuing dismay at this failure of >>> TI to conform to the ANSI standard -- it isn't a hard thing to >>> follow, and one breaks innumerable code libraries by using 32-bit >>> "double". >>> >>> Oh well, just another thing to take into account the next time I >>> select a processor.You selected a 16-bit fixed point processor for an application that required the use of double precision floating point?>> This gets worse yet for the 55xx. I just looked in the 55xx C/C++ >> Compiler Guide and apparently float = double = long double = 32-bit. >> I don't get why they even bother defining them!Presumably they defined them so that they could tick the "has ANSI-compliant C" box. I doubt that they ever expected anyone to actually use them at all. Different topic:> Why do people still want to do this, when standard names for these > things were defined in C99? Include stdint.h, use uint16_t, int32_t, > etc. and follow the standards. Its bad enough that C89 didn't specify > standard names for these things. Now we have them, please use them.Beats me. Unless they're well hidden, neither TI nor MS-Windows platforms have stdint.h, and have no standard file with the standard integer names in it. I use application-defined types exclusively, all named in a universally included "target.h" file according to the platform. Yes, that makes linking against other libraries entertaining, but for what I'm doing at the moment there isn't a lot of that to do. Cheerrs, -- Andrew
