Thread: Literals, how art thou used

Hi,

I'm working on some stuff for a TI F28335 DSP and I have a couple of questions regarding how the TI C89-compliant compiler handles literals:

(1)
unsigned int foo = 1; (I assume the literal '1' defaults to type 'int')

Would this require more "work" (cycles/instructions) than for instance:

unsigned int foo = 1U;

(2)
float foo = 1.0F/2.0F;

I assume the compiler produces instructions for the division that are handled by the FPU, but would this:

float foo = 1.0/2.0;

then be handled in software since the type of the literals defaults to 'double' (which is 64 bit on the DSP)?

(3)
I've read a bit about FPU's on modern 32 bit CPU's having 80 bit registers for temporary values. Does this mean that I can do 80 bit floating point operations on them, e.g.:

extprecision_t foo1 = 1.123 ... (80 bit worth);
extprecision_t foo2 = 2.123 ... (80 bit worth);
extprecision_t foo3 = foo1*foo2; (80 bit result)

?

Any help is greatly appreciated, thanks!

Edit:
Regarding question 2, I just realized that it was 'long double' that was 64 bit on the DSP. 'double' is probably 32 bit. But if we assume 'double' is 64 bit, would it trap to software or the like?

All of this stuff is clearly documented in manuals that are freely available from TI's website. There's also forums there, full of experts on the F28355 and TI's C compiler who are probably way more qualified than we are.

Originally Posted by milesyoung

(1)
unsigned int foo = 1; (I assume the literal '1' defaults to type 'int')

Would this require more "work" (cycles/instructions) than for instance:

unsigned int foo = 1U;

It will take a few more cycles to compile the code, simply because it has to read an extra character and do something about it, but that's probably not what you're interested in. It should not require more cycles when running the application on the DSP. I'm not very familiar with the TI DSPs, but I'm not aware of any processor for which the handling of signed and unsigned ints would differ in terms of numbers of cycles, especially just for a load. The documentation for the F28335 should tell how many cycles each instruction takes, so you can look at things like signed and unsigned addition, multiplication, etc. and compare for yourself. Anyway, unless you're writing critical real-time code and have concrete proof that your code is slow, and that you have already made all the algorithmic/architectural changes possible that will improve speed, you should ignore clock cycles and use the appropriate type. What you're asking about seems like a classic case of pre-optimization.

(2)
float foo = 1.0F/2.0F;

I assume the compiler produces instructions for the division that are handled by the FPU, but would this:

float foo = 1.0/2.0;

then be handled in software since the type of the literals defaults to 'double' (which is 64 bit on the DSP)?

A double is only 32 bits for you (this is in the documentation), and your chip only has a 32-bit FPU. IIRC, the C standard only says that all float values must be a subset of double, not a strict subset, so TI can (and does) use 32-bit doubles. From the compiler's point of view, it may be a double, but it's would still be a 32-bit value/operation, and would probably use the the FPU directly, not software. That's an assumption though, read the docs to be sure.

(3)
I've read a bit about FPU's on modern 32 bit CPU's having 80 bit registers for temporary values. Does this mean that I can do 80 bit floating point operations on them, e.g.:

extprecision_t foo1 = 1.123 ... (80 bit worth);
extprecision_t foo2 = 2.123 ... (80 bit worth);
extprecision_t foo3 = foo1*foo2; (80 bit result)

?

You're not using a "regular" modern 32 bit CPU. Almost certain you wont ever be able to get 80 bits (which is the size of 'long double' on many such CPUs), unless it's through some special TI-specific extension, but that's unlikely, since they already give long double as 64 bits. Again, read the docs.

Edit:
Regarding question 2, I just realized that it was 'long double' that was 64 bit on the DSP. 'double' is probably 32 bit. But if we assume 'double' is 64 bit, would it trap to software or the like?

No need to assume anything, the documentation clearly states that a double is 32 bits. The docs say something about "pass by reference" for long double type, but I didn't read beyond that. Don't know what other strange things the compiler does for long double types. They probably have to generate some extra instructions to handle 64 bit values/calculations.

If you haven't picked up on it yet, you need to read the docs .