From Texas Instruments Embedded Processors Wiki

Contents 1 Question 2 Answer 3 Question 4 Answer

Question

We wish to comply with an Industry Standard XX to justify safety or industry specific requirements for the tools we use. Is there a validation report or certificate available for the compiler?” (XX= IEC61508; TÜV; MISRA-C, etc.)

Answer

Special conformance testing of tools, compilers and runtime support libraries is the responsibility of the user.

TI performs extensive validation tests to ensure that the compiler generates correct ANSI C (C89) and C++ (1998) code. Additional industry specific tests such as IEC61508 safety tests or automotive TÜV safety tests are the responsibility of the user.

Question

Does the (current) C/C++ compiler comply to any norm (ISO, IEEE)?

Answer

All TI compilers support:

• C Standard: ANSI X3.159-1989 (C89), which is the same as ISO/IEC 9899:1990.
• C++ Standard: ISO/IEC 14882:1998

We do not support: C95, C99, C++ 2003, C++ TR1.

Though we do support, as language extensions, some C99 features. Two examples are the restrict keyword, and the header file stdint.h.

Leave a Comment

Comments

Perhaps there should be a caveat that DSP compliers are most decidedly NOT C89 compatible. To wit. If you have ANY int constants in an expression, the result is demoted to int, even if the result and several other operands are EXPLICITLY cast to longs. This is brain-damaged, and with no insult intended to Martians, the kind of thing I would expect from alien technology. OF COURSE the result of an expression should be promoted to the MOST inclusive data type of all the operands. Here it is in the standard:

3.2.1.5 Usual arithmetic conversions

  Many binary operators that expect operands of arithmetic type cause
  conversions and yield result types in a similar way.  The purpose is
  to yield a common type, which is also the type of the result.  This
  pattern is called the usual arithmetic conversions: First, if either
  operand has type long double, the other operand is converted to long
  double .  Otherwise, if either operand has type double, the other
  operand is converted to double.  Otherwise, if either operand has
  type float, the other operand is converted to float.  Otherwise, the
  integral promotions are performed on both operands.  Then the
  following rules are applied: If either operand has type unsigned long
  int, the other operand is converted to unsigned long int.
  Otherwise, if one operand has type long int and the other has type
  unsigned int, if a long int can represent all values of an unsigned
  int, the operand of type unsigned int is converted to long int ; if a
  long int cannot represent all the values of an unsigned int, both
  operands are converted to unsigned long int.  Otherwise, if either
  operand has type long int, the other operand is converted to long int.
  Otherwise, if either operand has type unsigned int, the other
  operand is converted to unsigned int.  Otherwise, both operands have
  type int.

  The values of operands and of the results of expressions may be
  represented in greater precision and range than that required by the
  type; the types are not changed thereby.

So tell me again how it can possibly be said that TI's DSP C-compilers are even remotely compliant with the above? There are many, many other examples:

- Enumerated Constants represented as floats - oh, and char is is 16 bits....

Please, somebody, slap them.

Georgem said ...

User:a0322393 says

It is true that there are some places where the TI compilers don't quite handle things as the standard specifies, but as far as usual arithmetic conversions go, the TI compilers adhere to the standard.

It is not the case that every operand in an expression should be promoted to the type of the widest type involved in the expression; this is a common misconception. The usual arithmetic conversion apply only on an operator-by-operator basis based on operator precedence. For example, on C55x, where "int" is 16 bits and "long" is 32 bits, the following expression does not compute a 16x16->32 multiply. Instead, it computes a 16x16->16 multiply, followed by an implicit conversion to 32 bits upon assignment to the long.

 extern int a, b;
 extern long x;
 x = a * b;

The compiler must examine the expression "x = a * b" in this way:

1. Since multiplication has higher precedence than assignment, we look at the multiplication first.
2. The operands of the multiplication are both 16-bit "int". Thus, by 3.2.1.5 (UAC), they are both left as "int."
3. Because the operands to the multiplication are "int" after UAC, the result of the multiplication is "int." (by paragraph 1, sentence 2 of 3.2.1.5)
4. Now one operand of the assignment operator is "long" and one is "int," so convert the "int" multiplication result to "long" (by UAC) and perform the assignment.

Even this does not perform a 16x16->32 multiplication:

 x = (long)(a * b);

The fact that there is a conversion to long cannot be considered until after the type of the result of the multiplication has been finalized.

A0322393 19:40, 9 February 2010 (UTC)