Literals, how art thou used

This is a discussion on Literals, how art thou used within the C Programming forums, part of the General Programming Boards category; Hi, I'm working on some stuff for a TI F28335 DSP and I have a couple of questions regarding how ...

  1. #1
    Registered User
    Join Date
    Apr 2012
    Posts
    2

    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?
    Last edited by milesyoung; 04-23-2012 at 02:08 PM.

  2. #2
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,425
    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.
    Quote Originally Posted by milesyoung View Post
    (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 .
    Last edited by anduril462; 04-23-2012 at 03:20 PM.

  3. #3
    Registered User
    Join Date
    Apr 2012
    Posts
    2

    Post

    Quote Originally Posted by anduril462
    It will take a few more cycles to compile the code...
    I thought the compiler might produce some instructions for run-time conversion, but that's probably not the case with the simple assignment I showed.

    Quote Originally Posted by anduril462
    You're not using a "regular" modern 32 bit CPU...
    I wasn't referring to the DSP in this case. I was talking about using "regular" CPU's.

    Thanks for your input

  4. #4
    Registered User
    Join Date
    Mar 2011
    Posts
    546
    there are specific rules in the C language for compile time integer promotion and conversion. in this case the signed '1' will be silently converted to unsigned at compile time. for literals most compilers would only give you a warning if the signed value is negative or wouldn't fit in the unsigned value.

    here is a good rundown of the compile time integer promotion/conversion rules.
    https://www.securecoding.cert.org/co...nversion+rules

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. My Network! Why hath thou forsaken me?
    By cpjust in forum Tech Board
    Replies: 10
    Last Post: 06-06-2010, 04:31 PM
  2. help! string literals
    By cakestler in forum C Programming
    Replies: 16
    Last Post: 02-05-2009, 10:41 AM
  3. Oh wonderful binary, where art thou?
    By cboard_member in forum C++ Programming
    Replies: 10
    Last Post: 07-15-2005, 12:00 PM
  4. Thou ark ........ed off...
    By CodeMonkey in forum Windows Programming
    Replies: 2
    Last Post: 11-29-2001, 02:35 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21