• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1417 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: [CCS/ARM Processor] how is the V (Overflow) Flag set in an ARM Processor?

chaithanya grb
Prodigy 130 points

Tool/software: TI C/C++ Compiler

how is the V (Overflow) Flag set in an ARMCL Processor?

Got the understanding from the manuals, “Overflow flag will be set, if the result of an add, subtract, or compare is greater than or equal to 231, or less than -231 and if you add to positives and get a negative or subtract to negatives and get a positive!

Below are the scenarios which I tried. In both the case

CASE #1

   int of_check = 0xFFFFFFFF;

   of_check++;

   of_check++;

   *((uint32*)0xc002002C) = of_check;

 

CASE #2:

   int range1 = 0x7fffffff;

   int range2 = 0x7fffffff;

   int res;

   res = range1 + range2;

   *((uint32*)0xc0020030) = res;

CASE #3:

   int a = 0x80000000;

   int b = 0x10000000;

   int result = a+b;

   *((int*)0xc0020030) = result;

Note* : When I try the above case, the corresponding object code is not generated by the ARMCL compiler.

 

 

My Question is,

  1. How is the V-Flag set?
  2. Why V-Flag is not set for the cases which I tried?
  3. How the ARMCL compiler eliminates the code in object file case#3, without generating the warning/Error while building the application?

  • 0
    TI__Guru**** 249680 points

    It is not a good idea to explore the overflow behavior of a CPU through C code.  Here is what the ANSI standard for C has to say on this topic ...

    If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

    This is from the C99 standard, section 6.5.  

    The bottom line is the compiler assumes an exceptional condition, including overflow, never occurs.

    The best way to explore overflow behavior is through hand-coded assembly.  

    All that said, in keeping with the general idea of your post, here is a suggestion to consider.  In separate files, write code similar to ...

    /* file1.c */

test_add_overflow(0xffffffff, 1);
test_add_overflow(0x7fffffff, 0x7fffffff);

/* file2.c */
int test_add_overflow(int arg1, int arg2)
{
    return arg1 + arg2;
}

    Single step through the assembly instructions generated for test_add_overflow, and see how status bits, like overflow, are affected.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 130 points
    Hi George,

    The scenario which i tried wont cause the overflow. Actually "0xffffffff" is -1 .
    #1) 0xffffffff+ 1 = 0
    #2) 0x7fffffff +0x7fffffff = -2
    The above resultant values will not cause the overflow as this falls in valid integer range( -2,147,483,648 to 2,147,483,647).

    -Thanks